Журнал для ext4 на отдельной партиции

а размер раздела не быть меньше, чем 1024 * BlockSize, но каким он должен быть?

Он должен быть не менее, чем 1024 * BlockSize. «Звёздочка» обозначает операцию умножения, 1024 это такое число, BlockSize это размер блока, для существующей ФС его можно узнать из вывода ″tune2fs -l″, обычно 4096 байт. То есть обычно раздел для журнала должен быть не менее 4 Мбайт.

http://www.raid6.com.au/posts/fs_ext4_external_journal_caveats/

Для 3 Тб я бы посоветовал от 512 Мб до 1-1.5 Гб. Можно даже больше, но не уверен, что нужно.

man mkfs.ext4 говорит, что размеры блоков должны совпадать, а размер раздела не быть меньше, чем 1024 * BlockSize, но каким он должен быть?

блок имеет размер 4096 байт. Можно меньше, если речь про HDD меньше 100 МЕГАбайт. (таких не бывает уже лет 15..20).

Ок, потестирую ввод-вывод для файловой системы с подобной конфигурацией.
Если не секрет, эти цифры из каких-либо гайдов по файловой системе или свой собственный практический опыт?

Ок, я не корректно выразился, извините. То что при стандартном 4К блоке минимальный размер журнала - 4МБ мне понятно. Интересовало другое, какой размер был бы оптимальным?
Похоже предстоит выяснить опытным путем. В любом случае, спасибо всем отписавшимся.

а в чём смысл выносить журнал на ssd?

Если не секрет, эти цифры из каких-либо гайдов по файловой системе или свой собственный практический опыт?

Опыт. Сейчас точно не припомню, но я сравнивал производительность на разных размерах и пришёл к выводу, что на каждый терабайт желательно делать не менее 512 Мб журнала. Особенно актуально с data=journal, с data=ordered выигрыш будет не на любой нагрузке.

В теории (как я это понимаю), ускорение операций записи на винт.

• Фактические изменения должны проходить через журнал \
  
• Журнал на SSD, данные на HDD \
  
• Ресурсы винта не деляться на запись пользовательских и журнальных данных \
  
• Задержки короче \
  
• Profit!

Плюс в ext4 реализован подсчет контрольных сумм журнала, думаю тут SSD тоже лишним не будет.
На практике, пока готовлю тесты для fio, очищаю накопители. Как говорится, будем посмотреть.

Без data=journal это бессмысленно. И этот режим не особо то и нужен.

Похоже на то, что товарищи aidaho и Gotf оказались правы. В моем случае параметр data при монтировании играл решающую роль.

• С параметром data=ordered
  • fio в режиме randrw и независимо от глубины очереди и количества потоков показал схожие иопсы, с небольшим преимуществом варианта без external journal device;
  • fio в режиме write (последовательная запись) показал небольшое преимущество внешнего журнала для файловой системы;
  • fio в режиме randwr (случайная запись) показал его же серьезное отстование (для меня не совсем понятно почему);
• С параметром data=journal, неоспоримое преимущество журнала файловой системы на SSD во всех режимах тестирования.
  Осталось лишь придумать для data=journal применение в реальной жизни.

Результаты для разделов под журнал от 1.5 ГБ и выше примерно схожи, различия списаны на погрешности измерений.
Разумеется не исключаю своих ошибок при тестировании.

Create a journal stored in the filesystem of size journal-size megabytes. The size of the journal must be at least 1024 filesystem blocks (i.e., 1MB if using 1k blocks, 4MB if using 4k blocks, etc.) and may be no more than 102,400 filesystem blocks. There must be enough free space in the filesystem to create a journal of that size.
Так что больше чем 400 мегабайт журнал делать смысла нет.

Количество идиотов в теме зашкаливает, включая спрашивающего, который ищет способ убить свой SSD.

Я даже промолчу, что большинству людей журнал на ext4 вообще не нужен. Его тупо можно отключить (-O ^has_journal).

// b.

для меня не совсем понятно почему

Я и сам не знаю, но помню, что непредсказуемые задержки на записи с data=ordered в реальных применениях послужили основной причиной смены дефолта на writeback.