LINUX.ORG.RU
ФорумAdmin

Realtime раздел у XFS. Файлы отдельно, inode'ы отдельно.

 , , , ,


7

4

Уважаемый pon4ik, поднял недавно тут тему как сделать так, чтобы «ФС ... хранила бы метаданные на одном диске, а сами данные на втором. Т.е. пока происходят всякие listdir и fstat не было обращений к харду и он мог сладко спать.»

Я вспомнил, что об XFS слышал подобное, быстро нагуглил пару ссылок про realtime раздел и кинул в коментариях. Но так-как я XFS-boy, то полез смотреть как оно реализовано. Рапортую). Realtime раздел у XFS — это дополнительный раздел на который пишутся только данные (не inode'ы и не лог — первые пишутся на основной раздел, вторые или на него же или на отдельный раздел, если указать). Соответственно можно вынести данные в больших файлах с последовательным доступом на один раздел, а все IOPS'затратные операции на другой раздел на SSD или даже в оперативке (если сохранность данных нужна только до перезагрузки, бывает такое).

Как реализовать:

mkfs.xfs -r rtdev=/dev/sdb /dev/sdc
или
mkfs.xfs -l logdev=/dev/sdd -r rtdev=/dev/sdb /dev/sdc

Где:
/dev/sdb — realtime раздел (только файлы и только если об этом «попросить», об этом ниже)
/dev/sdc — основной раздел (файлы, inode'ы, log)
/dev/sdd — раздел для log'а ФС

Лог раздел имеет ограничение по размерам. Поэтому легче его не выносить, учитывая что мы и так выносим от «главного» раздела файлы.

Далее монтируем:

mount -o rtdev=/dev/sdb /dev/sdc /mnt
или
mount -o logdev=/dev/sdd,rtdev=/dev/sdb /dev/sdc /mnt

Как заставить систему писать файлы на realtime раздел? Есть 3 варианта:

  • 1. Опция
    mkfs.xfs -d rtinherit=1
     — это недокументированная опция, которая говорит, что на созданной ФС все файлы будут писаться на Realtime раздел.
  • 2. Команда
    xfs_io -c "chattr +t" /mnt/
     — ставит на директорию атрибут «realtime inheritance». Все файлы созданные после этого в директории будут записаны в rt раздел. Атрибут можно ставить на директорию в которую примантирована ФС (и даже на ней атрибут сохраняется после перемонтирования).
  • 3. Команда
    xfs_io -c "chattr +r" /mnt/file_name
     — ставит на файл атрибут «the realtime». Файл должен быть создан пустым для этого (touch /mnt/file_name подходит).

Какова стабильность решения? После обсуждения год назад патчей для realtime разделов (подробнее тут: https://patchwork.kernel.org/patch/9933237/ ), началось активное тестирования этого функционала в XFS, были исправлены несколько багов, а в xfstests добавлен функционал по тестированию ФС с realtime разделом.

★★

Последнее исправление: chaos_dremel (всего исправлений: 7)

Огромное спасибо, за столь развернутый ответ. Теперь,я просто обязан попробовать твою любимую фс :)

pon4ik ★★★★★
()

Спасибо за информацию. Я тоже был xfs-фанбоем, когда это ещё не было мейнстримом.

d ★★★★
()
Ответ на: комментарий от Dark_SavanT

Ты видимо хотел спросить насколько проседает? Вот тоже интересно, хотя все эти метаданные логичней выносить на жёсткий диск, а сами данные хранить на носителе на котором хочется минимизировать записи и бесплатные чтения (твердотельный накопитель, может быть даже оптане).

anonymous
()
Ответ на: комментарий от Dark_SavanT

Вот что пишет автор темы про патчи:

Sorry I forgot to clarify the origins of the performance wins here. This is obviously very workload dependent (e.g. write/flush/inode updatey workloads benefit the most) but for our use case about ~65% of the IOP savings (~1/3 journal + slightly less than 1/3 sync of metadata from journal, slightly less as some journal entries get canceled), the remainder 1/3 of the win comes from reading small files from the SSD vs. HDDs (about 25-30% of our file population is <=256k; depending on the cluster). To be clear, we don't split files, we store all data blocks of the files either entirely on the SSD (e.g. small files <=256k) and the rest on the real-time HDD device. The basic principal here being that, larger files MIGHT have small IOPs to them (in our use-case this happens to be rare, but not impossible), but small files always do, and when 25-30% of your population is small...that's a big chunk of your IOPs.

Я сейчас провожу тесты, когда закончу — выложу отдельным постом, можно будет обсудить.

chaos_dremel ★★
() автор топика
Ответ на: комментарий от pon4ik

Да это я поставил в посте тег «производительность», потому как напрашивался. Да и вообще интересен прирост, например при работе с огромным количеством мелких файлов, ведь по идее вынос всего кроме самих файлов на SSD должен дать нехилый прирост производительности.

chaos_dremel ★★
() автор топика
Ответ на: комментарий от chaos_dremel

Короче, это даёт ощутимый вин на работе с кучей мелкий файлов(потому что шерстим inodes которые на ssd). Надо будет запомнить, спасибо.

Dark_SavanT ★★★★★
()
Ответ на: комментарий от Dark_SavanT

Где главное, насколько меняется производительность?

Наверно, приблизительно ни насколько.

Partisan ★★★★
()

А как мониторятся загруженность этих разделов и как их расширять? Как обычно - понятно. А тут что где смотреть и как расширять?

anonymous
()
Ответ на: комментарий от Dark_SavanT

Да прирост при мелких файла/работе мелкими блоками (тут больше из-за лога) и падение производительности на больших файлах (но скорее всего только на HDD) из-за того, что на RT разделе нет обычной структуры XFS c allocation group.

chaos_dremel ★★
() автор топика
Ответ на: комментарий от anonymous

Очень хороший вопрос. Забыл написать про этот нюанс. Обычные способы мониторинга свободного места на RT разделах не работают. Опять же по ссылке в посте есть небольшое обсуждение касательно команды df и т.п.

2. rtstatfs - Returning real-time block device free space instead of the non-realtime device via the «rtstatfs» flag. This creates an experience/semantics which is a bit more familiar to users if they use real-time in a tiering configuration. «df» reports the space on your HDDs, and the metadata space can be returned by a tool like xfs_info (I have patches for this too if there is interest) or xfs_io. I think this might be a bit more intuitive for the masses than the reverse (having to goto xfs_io for the HDD space, and df for the SSD metadata).

Yep, useful idea. We already have a mechanism for reporting different information to statfs depending on what is passed to it.
We use that to report directory tree quota information instead of filesystem wide information. See the project id inode flag hooks at the end of xfs_fs_statfs().
Similar could be done here - if statfs is pointed at a RT file/directory, report rt device usage. If it's pointed at a the root directory, report data device information.

Собственно xfs_io о котором говориться юзается, насколько я понимаю, так (/mnt — любой файл на точке монтирования включая саму точку монтирования):

xfs_io -c "statfs" /mnt
Где нас интересуют строки
geom.rtblocks = 2560000
geom.rtextents = 2560000
counts.freertx = 2297856
Последнее это количество свободных экстентов, в моём случае по они 4КБ (раздел в 10ГБ, около 1ГБ занято).

chaos_dremel ★★
() автор топика
Последнее исправление: chaos_dremel (всего исправлений: 3)
Ответ на: комментарий от post-factum

Хм, цефоды давно так делали. Думал не прижилось по каким-то объективным причинам, а оно оказывается что массы не знали как это делается.

Deleted
()
Ответ на: комментарий от anonymous

По поводу изменений размера. xfs_growfs имеет такие опции:

-R size     grow realtime section to size blks
-e size     set realtime extent size to size blks

chaos_dremel ★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.