XFS: Mount overrides параметры sunit и swidth

Question

У меня есть раздел XFS размером 9 ТБ, состоящий из четырех дисков по 3 ТБ в массиве RAID-5 с размером порции 256 КБ, с использованием MDADM.

Когда я создал раздел, оптимальные значения полосы и ширины полосы (64 и 192 блока) были обнаружены и установлены автоматически, что подтверждает xfs_info:

# 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

Тем не менее, я испытывал медленные скорости передачи, и во время исследования я заметил, что, если я специально не монтирую раздел с -o sunit=64,swidth=192 , единица измерения полосы всегда будет установлена на 512, а ширина на 1536. Например:

# 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

Это намеренное поведение? Я предполагаю, что я мог бы просто начать монтировать его с sunit=64,swidth=192 каждый раз, но разве это не сделало бы текущие данные (которые были записаны при монтировании с sunit=512,swidth=1536) смещенными ?

Операционная система Debian Wheezy с ядром 3.2.51. Все четыре жестких диска являются дисками расширенного формата (smartctl говорит, что 512 bytes logical, 4096 bytes physical). Тот факт, что значения умножены на 8, заставляет меня задуматься, имеет ли это какое-либо отношение к проблеме, поскольку она соответствует коэффициенту умножения между дисками размером от 512 до 4096 секторов.

Может кто-нибудь пролить некоторый свет на это? :-)

Answer 1

Ваша загадка, умноженная на 8, заключается в том, что xfs_info показывает sunit/swidth в блоках bsize, обычно 4096 байт. При указании sunit/swidth в mount с помощью -o или fstab они указываются в 512-байтовых единицах. Обратите внимание на строку "blks" после чисел sunit/swidth в вашем примере вывода xfs_info. 4096/512 = 8, отсюда и загадочный множитель.

man 5 xfs разъясняет это в строфе sunit, как и mkfs.xfs, в отношении 512B юнитов.

В man xfs_growfs, который удваивается как man-страница для xfs_info, объясняется, как единицы измерения для xfs_info являются байтами в байтах.

Смущает, да. Очень плохой выбор дизайна с точки зрения пользовательского интерфейса, да.

Указание «-o sunit = 64, swidth = 192», вероятно, было плохой идеей, так как на самом деле вы хотели 64/8 = 8 и 192/8 = 24. Вы, возможно, "жестко закодировали" 8-кратные значения в FS, теперь установив их с большими числами. Страница man довольно ясно говорит о том, что никогда не сможет переключиться на более низкий сунит. Тем не менее, вы можете попробовать и посмотреть, если вы получите ошибки монтирования. Монтирование для XFS должно (но не гарантирует) быть достаточно надежным, чтобы не поглощать ваши данные: оно должно просто выдавать ошибку и отказываться от монтирования, или монтироваться с опциональными параметрами, игнорируя то, что вы указали. Сделайте резервные копии в первую очередь.

Тем не менее, на самом деле не может быть ничего плохого в увеличении sunit/swidth в 8 раз, так как это все о выравнивании, и эти числа все еще выровнены. Возможно, могут быть проблемы фрагментации или проблемы, если большинство ваших файлов крошечные?

Кроме того, над чем я сейчас работаю и заинтриговываю, так это то, что нужно изменить значения sunit/swidth, когда вы увеличиваете / изменяете свой md RAID, добавляя 1 диск. Из справочной страницы кажется, что вы не можете изменить sunit, если вы буквально не удвоите количество дисков, но кажется, что изменение ширины все еще возможно. Приводит ли это к правильному выравниванию в большинстве случаев, еще неизвестно. Информация от людей, делающих это, кажется скудной.