Выбор файловой системы

Конечно, она ведь расчитана на работу с крупными файлами.

Правильнее написать: она не расчитана на работу с мелкими файлами. С крупными-то работать не проблема вообще.

Не доверяю я свои личные файлы неопробованной файловой системе. Одно дело, если посыпется корень — ну, чрутнусь, попробую починить. В крайнем случае — переустановка системы. А если что-то произойдет с хомяком — это капут.

max_inline=16384

А что это за опция, кстати?

Задаёт размер файлов в байтах, которые будут упаковываться прямо в дерево метаданных. Думаю, чем больше файлов будет прямо в дереве - тем меньше головкам харда придётся скакать туда-сюда, соответственно, ФС будет работать быстрее. Могу ошибаться.

Спасибо большое за ответ! Я еще погуглю на эту тему.

Прочитал, что это значение ограничено размером блока файловой системы. Его можно задть при создании фс командой mkfs с помощью атрибута sectorsize.

Спорный момент. Файловые системы работающие с блоками данных, а не экстентами вынуждены при обращении к большим файлам работать с огромным масивом данных, что ограничивает поддержку действительно больших файлов. Так максимальный размер файла в ext4 — 16ТБ (в ext3 был 2ТБ). Это конечно достаточно много (как для десктопных систем), но, как показывает практика, нюансы в производительности ext4 с большими файлами начинаются намного раньше.

НУ и собственно «не расчитана на работу с мелкими файлами» уже давно не актуально.

экстенты

Да, когда XFS проектировали, это имело значение. А какая из актуальных ФС сейчас не работает с экстентами?

но, как показывает практика, нюансы в производительности ext4 с большими файлами начинаются намного раньше.

Связанные с реализацией драйвера или со структурами ФС?

Собственно экстенты появились только в ext4. Я не знаю, как они были реализованы, но, учитывая, что драйвер ext4 сохраняет совместимость с ext2/3, а сама ФС может быть «сконвертирована», у меня есть ощущение, что их просто навесили сверху на уже существующую структуру ФС (малая разница в максимальном размере файла, тоже наводит на эту мысль). Соотсветственно ограничения связаны с со структурой ФС, а производительность, скорее всего, с тем, что драйвер и структура сохраняют обратную совместимость, что накладывает ограничения на возможности исправить работу с большими файлами.

Кстати, если мне не изменяет память, btrfs как раз создавалась с мыслью исправить эти ограничения.

Вот ещё интересные рекомендации от Red Hat по максимальному объёму файлов и разделов для разных ФС. https://access.redhat.com/solutions/1532

Привет! Я потихоньку подумываю над переходом на Арч.

Поставишь i3 и будешь някать?

Собственно экстенты появились только в ext4

Как минимум ещё в btrfs. Ты точно настоящий сварщик?

Речь же про линейку ext2/3/4. В ext2/3 экстентов нет. В ext4 — есть. А так, да, они много где есть. Вот вчера писал про то, как XFS их использует. Логика размещения файлов в ФС (комментарий)

Эй агильщик-могильщик иди поведай свои знания где-нибудь в другом месте, например в сумасшедшем доме.

Не забывайте на btrfs делать бэкапы (была пара фейлов), расставлять теги без-copy-on-write для всяких образов виртуальных дисков и периодически запускать чистку с дефрагментацией. Иначе за 3-6 месяцев плавно и незаметно производительность скатится.

У меня в опциях монтирования autodefrag, так что деградировать не должно.

Местные btrfs-воды советуют не пренебрегать btrfsmaintenance

btrfs - мнимое «Не осталось свободного места» (комментарий)

Странная дисковая активность не даёт заснуть HDD. (комментарий)