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

ЛОР торт. Раз в год.

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

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

Вопрос был не сколько про производительность, сколько про максимально редкое включение питания на хдд.

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

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

Когда еще IRIX был хив? :)

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

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.

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

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

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

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

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

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

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

Очень хороший вопрос. Забыл написать про этот нюанс. Обычные способы мониторинга свободного места на 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

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

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

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