md raid1 Os setores ext3 e 4k são lentos com as operações de diretório

Question

Recentemente, mudei de um gabinete RAID1 de hardware para usar duas unidades eSATA com md. Tudo parece estar funcionando bem, exceto pelo fato de que percursos de diretórios / listagens às vezes rastreiam (na ordem de 10 segundos). Estou usando um sistema de arquivos ext3, com o tamanho do bloco definido para 4K.

Aqui estão alguns resultados relevantes dos comandos que devem ser importantes:

mdadm --detail:

/dev/md127:
        Version : 1.2
  Creation Time : Sat Nov 16 09:46:52 2013
     Raid Level : raid1
     Array Size : 976630336 (931.39 GiB 1000.07 GB)
  Used Dev Size : 976630336 (931.39 GiB 1000.07 GB)
   Raid Devices : 2
  Total Devices : 2
    Persistence : Superblock is persistent

    Update Time : Tue Nov 19 01:07:59 2013
          State : clean
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

         Events : 19691

    Number   Major   Minor   RaidDevice State
       2       8       17        0      active sync   /dev/sdb1
       1       8        1        1      active sync   /dev/sda1

fdisk -l / dev / sd {a, b}:

Disk /dev/sda: 1000.2 GB, 1000204886016 bytes, 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0xb410a639

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1            2048  1953525167   976761560   83  Linux

Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes, 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x261c8b44

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1            2048  1953525167   976761560   83  Linux

time dumpe2fs / dev / md127 | tamanho do grep:

dumpe2fs 1.42.7 (21-Jan-2013)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
Block size:               4096
Fragment size:            4096
Inode size:               256
Required extra isize:     28
Desired extra isize:      28
Journal size:             128M

real    2m14.242s
user    0m2.286s
sys     0m0.352s

Do jeito que eu entendi, eu tenho setores 4K nessas unidades (recentes WD reds), mas as partições / sistemas de arquivos parecem estar corretamente alinhados. Como parece que estou usando a versão 1.2 do metadado md, também acho que estou bem (com base em mdadm raid1 e o que é chunksize (ou blocksize) em drives de 4k? ). A única coisa que eu não encontrei uma resposta para on-line é se ter ou não um tamanho de inode de 256 causaria problemas. Nem todas as operações são lentas, parece que o cache de buffer faz um ótimo trabalho de manter as coisas zippy (como deveria).

Minha versão do kernel é 3.11.2

EDIT: nova informação, 2013-11-19

mdadm --examine /dev/sd{a,b}1 | grep -i offset
    Data Offset : 262144 sectors
   Super Offset : 8 sectors
    Data Offset : 262144 sectors
   Super Offset : 8 sectors

Além disso, estou montando o sistema de arquivos com noatime,nodiratime . Não estou realmente disposto a mexer muito com o registro no diário, pois se eu me importar o suficiente para ter o RAID1, ele pode ser autodestrutivo. Estou tentado a ativar a indexação de diretório

EDIT 2013-11-20

Ontem, tentei ativar a indexação de diretório para ext3 e executei e2fsck -D -f para ver se isso ajudaria. Infelizmente, isso não aconteceu. Eu estou começando a suspeitar que pode ser um problema de hardware (ou é md raid1 sobre eSATA apenas muito estúpido para fazer?). Estou pensando em colocar cada uma das unidades offline e ver como elas funcionam sozinhas.

EDIT 2013-11-21

iostat -kx 10 | grep -P "(sda | sdb | Device)":

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.37     1.17    0.06    0.11     1.80     5.10    84.44     0.03  165.91   64.66  221.40 100.61   1.64
sdb              13.72     1.17    2.46    0.11   110.89     5.10    90.34     0.08   32.02    6.46  628.90   9.94   2.55
Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
sdb               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00

Eu trunquei a saída depois disso, pois era tudo 0,00%

Eu realmente sinto que deve ser independente de ext4 vs. ext3 porque isso não é apenas um pouco mais lento, pode levar da ordem de dezenas de segundos a um minuto, e algumas alterações na guia completam automaticamente ou são executadas um ls

EDIT: Provável problema de hardware, fechará a questão quando confirmado

Quanto mais penso nisso, mais me pergunto se é o meu cartão eSATA. No momento, estou usando este: link No entanto, acabei de verificar o dmesg e ele está cheio dessas mensagens:

[363802.847117] ata1.00: status: { DRDY }
[363802.847121] ata1: hard resetting link
[363804.979044] ata2: softreset failed (SRST command error)
[363804.979047] ata2: reset failed (errno=-5), retrying in 8 secs
[363804.979059] ata1: softreset failed (SRST command error)
[363804.979064] ata1: reset failed (errno=-5), retrying in 8 secs
[363812.847047] ata1: hard resetting link
[363812.847061] ata2: hard resetting link
[363814.979063] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 10)
[363814.979106] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 10)
....
[364598.751086] ata2.00: status: { DRDY }
[364598.751091] ata2: hard resetting link
[364600.883031] ata2: softreset failed (SRST command error)
[364600.883038] ata2: reset failed (errno=-5), retrying in 8 secs
[364608.751043] ata2: hard resetting link
[364610.883050] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 10)
[364610.884328] ata2.00: configured for UDMA/100
[364610.884336] ata2.00: device reported invalid CHS sector 0
[364610.884342] ata2: EH complete

Também vou comprar cabos eSATA blindados mais curtos, já que estou pensando se há alguma interferência acontecendo.

    

Answer 1

ISTO TERMINOU COMO UM PROBLEMA DE HARDWARE

Mudar para os novos cabos blindados não ajudou, mas substituir o cartão antigo por este: link livrar-se das mensagens de erro e do comportamento estranho. Postará algo novo se alguma coisa mudar.

NOTA IMPORTANTE PARA ARQUIVOS SATA:

Mesmo depois de fazer o acima, qualquer operação da unidade seria incrivelmente lenta (apenas parar por 10 a 30 segundos) sempre que a unidade estivesse inativa por um tempo. O gabinete que estou usando tem uma interface eSATA, mas é alimentado por USB. Eu determinei que isso era porque não tinha energia suficiente para girar, então tentei algumas coisas:

• Usando uma fonte de energia USB de corrente mais alta externa (no caso de as portas estarem fazendo apenas o mínimo de 500 mA)
• Desativando o spin-down com hdparm -S 0 /dev/sdX (isso aliviou bastante o problema, mas não o resolveu completamente)
• Desativado gerenciamento avançado de energia via hdparm -B 255 /dev/sdX (novamente, não resolveu totalmente)

Eventualmente, descobri que a Western Digital tem uma configuração de jumper para o Reduced Power Spinup - projetado especialmente para esse caso de uso!

As unidades que estou usando são: WD Red WD10JFCX 1TB IntelliPower 2.5 " link

Observe que ainda estou operando sem todos os recursos de gerenciamento de energia e rotação (Ainda -B 255 e -S 0 no hdparm).

Veredicto final

Infelizmente, o RPS não resolveu todos os meus problemas, apenas reduziu a magnitude e a frequência. Acredito que os problemas se devam ao fato de que o gabinete não poderia fornecer energia suficiente (mesmo quando eu uso um adaptador AC-USB). Eu finalmente comprei este recinto:

link

e tudo tem funcionado sem falhas nas últimas três semanas.