XFS: Mount sobrescreve as opções sunit e swidth

Question

Eu tenho uma partição XFS de 9 TB que consiste em quatro discos de 3 TB em uma matriz RAID-5 com um tamanho de bloco de 256 KB, usando o MDADM.

Quando criei a partição, os valores ideais de unidade de faixa e largura (64 e 192 blocos) foram detectados e definidos automaticamente, o que xfs_info confirma:

# xfs_info /dev/md3
meta-data=/dev/md3               isize=256    agcount=32, agsize=68675072 blks
         =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=2197600704, imaxpct=5
         =                       sunit=64     swidth=192 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=521728, version=2
         =                       sectsz=512   sunit=64 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

No entanto, eu estava tendo velocidades de transferência lentas e, ao investigar, percebi que, a menos que eu monte a partição especificamente com -o sunit=64,swidth=192 , a unidade de distribuição é sempre definida como 512 e a largura como 1536. Por exemplo:

# umount /dev/md3
# mount -t xfs -o rw,inode64 /dev/md3 /data
# grep xfs /proc/mounts
/dev/md3 /data xfs rw,relatime,attr2,delaylog,inode64,logbsize=256k,sunit=512,swidth=1536,noquota 0 0

Esse comportamento é pretendido? Eu suponho que eu poderia começar a montá-lo com sunit=64,swidth=192 todas as vezes, mas isso não tornaria os dados atuais (que foram escritos enquanto montados com sunit=512,swidth=1536 ) desalinhados?

O sistema operacional é o Debian Wheezy com o kernel 3.2.51. Todos os quatro discos rígidos são discos de formato avançado (smartctl diz 512 bytes logical, 4096 bytes physical ). O fato de os valores serem multiplicados por 8 faz com que eu me pergunte se isso tem alguma relação com o problema, visto que ele corresponde ao fator de multiplicação entre 512 e 4096 tamanhos de setor.

Alguém pode lançar alguma luz sobre isso? : -)

    

Answer 1

Seu mistério multiplicar-por-8 é porque xfs_info mostra sunit / swidth em blocos bsize, normalmente 4096 bytes. Ao especificar sunit / swidth na montagem com -o ou fstab, eles são especificados em unidades de 512 bytes. Observe a string "blks" após os números sunit / swidth na sua saída xfs_info de amostra. 4096/512 = 8, daí o multiplicador do mistério.

man 5 xfs escreve isso na estrofe sunit, assim como mkfs.xfs, em relação a 512B unidades.

man xfs_growfs, que duplica como a página de manual de xfs_info, explicita como as unidades de xfs_info são bytes de bsize.

Confuso, sim. Escolha de design muito ruim do ponto de vista da interface do usuário, sim.

Especificar "-o sunit = 64, swidth = 192" foi provavelmente uma má idéia, já que você realmente queria 64/8 = 8 e 192/8 = 24. Você pode ter "codificado" os valores 8 vezes maiores no FS, agora com os números maiores. A página man é bastante explícita sobre nunca ser capaz de mudar para um sunit mais baixo. No entanto, você provavelmente poderia tentar e ver se obtivesse erros de montagem. Montar para XFS deve (mas não garantias) ser robusto o suficiente para não comer seus dados: ele deve apenas cuspir um erro e se recusar a montar, ou montar com opções sãs ignorando o que você especificar. Faça backups primeiro.

Dito isto, pode não haver nada de errado com o sunit / swidth 8 vezes maior, pois isso é tudo sobre alinhamento, e esses números ainda estão alinhados. Talvez haja problemas ou problemas de fragmentação se a maioria de seus arquivos é pequena?

Além disso, o que eu estou trabalhando agora e achar intrigante é o que mudar os valores sunit / swidth para quando você crescer / remodelar seu md RAID adicionando 1 disco. A partir da página man, parece que você não pode mudar o sunit, a menos que você literalmente dobre o número de discos, mas parece que mudar o swidth ainda é possível. Se isso resulta em um alinhamento adequado na maioria dos casos, ainda precisa ser visto. As informações das pessoas que realmente fazem isso parecem escassas.