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

Question

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

2914

Sauron 2014-01-13 в 17:19

У меня есть раздел 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 секторов.

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

2

Параметры монтирования не могут перемещать существующие данные относительно геометрии полосы базового блочного устройства. Либо ваши данные на диске выровнены, либо нет. К счастью, выравнивание гораздо важнее для записей на RAID5, чем для чтения. Так что это не проблема, за исключением файлов, таких как образы виртуальных машин, файлы подкачки или другие вещи, которые могут быть перезаписаны на месте (БЕЗ усечения, например, dd `conv = notrunc`). Peter Cordes 9 лет назад 0

См. Https://raid.wiki.kernel.org/index.php/RAID_setup#XFS, чтобы узнать, как создать XFS на RAID, если автоопределение базовой геометрии полосы не сработало. Peter Cordes 9 лет назад 0

Большие размеры полос подходят для большинства вещей в наши дни. Ширина полосы 512 Кб разумна. Команды ввода / вывода, отправляемые на аппаратные средства, могут выполняться в довольно больших единицах, поэтому меньшие размеры чередования приводят к меньшим аппаратным командам, чем было бы оптимальным. На https://raid.wiki.kernel.org/index.php/Performance есть некоторые старые вещи, и некоторые ссылки не работают. Небольшие порции для RAID5 могут быть оправданы, если у вас есть рабочая нагрузка с интенсивной записью, которая позволяет группировать запросы в последовательные порции до определенного размера, но не больше. Установите размер фрагмента, чтобы сделать крышку для записи полной полосой. Peter Cordes 9 лет назад 0

1 ответ на вопрос

3

Accepted Answer · 2014-09-10 08:05:15

Ваша загадка, умноженная на 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 представляют собой байты bsize.

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

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

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

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

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

1 ответ на вопрос

Похожие вопросы