Посоветуйте файловую систему для большого раздела с мультимедиа

А зачем на отдельном жёстком диске, который будёт файлопомойкой, LVM?

Ну… Можно будет заводить mirror/stripe/raid5 тома, вертеть их размер, добавлять, убирать диски. Если нет внезапных отрубаний питания и ядерных паник, должно работать как часы.

389G для 20T тома - это всего лишь незначительные 2%, забить

389G — это дофига.

$ df -h /mnt/media/
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg-media  500G  378G  123G  76% /mnt/media

Тратить это место на чексуммы для торрентовой мультимедиа на локалхосте — расточительство.

И в этой ситуации нужно обращаться за восстановлением данных, если критичны изменённые данные с момента последнего бэкапа или их бэкап вовсе не делался, а полагались только на RAID.

Вижу это так: для важных данных lvm-том в режиме -m 3 (4 диска), для всего остального — просто обычный lvm-раздел, а то и stripe на 4 диска для каких-нибудь LLM-ок с huggingface.

Вылетает один диск — не беда. Важные данные все еще в трех экземплярах, а неважные — частично в /dev/null. Непонятно разве что, как в такой ситуации вытащить с зааффекченных разделов целые файлы. Но, думаю, эта проблема уже много кем решена.

для торрентовой мультимедиа на локалхосте — расточительство.

Без них, появится ошибка и будут качать одну и туже часть бесконечное количество раз, расточительно загружая сеть.

xfs подкупает тем, что не надо думать о количестве инод.

Тут вопрос надо ставить так: сколько файлов и какого среднего размера должно быть на диске, чтобы это стало проблемой? В комментариях вроде пытались давать оценки, но как-то неубедительно.

Не то чтобы я с этим сталкивался у себя на десктопе, но мало ли.

Вот-вот. Лично я исхожу из того, что есть проблемы, решением которых прямо сейчас заниматься смысла нет.

Держу файлопомойку с мультимедией именно на ext4, правда, мой диск поменьше твоего, признаю. И если я наткнусь на проблему с инодами – то я, скорее всего, задумаюсь о том, что у меня многовато файлов на одном диске, и пора бы добавить ещё один диск, а заодно эту помойку реорганизовать (время от времени это полезно делать даже без проблемы с инодами).

Не? Не подходит такая логика? Если нет, то почему?

Тут Алису осенило.
– Поэтому здесь и накрыто к чаю? спросила она.
– Да, - отвечал Болванщик со вздохом. – Здесь всегда пора пить чай. Мы не успеваем даже посуду вымыть!
– И просто пересаживаетесь, да? – догадалась Алиса.
– Совершенно верно, - сказал Болванщик. – Выпьем чашку и пересядем к следующей.
– А когда дойдете до конца, тогда что? – рискнула спросить Алиса.
– А что, если мы переменим тему? – спросил Мартовский Заяц и широко зевнул.

Другими словами: проблемы с проверенной временем ext4 действительно настолько велики, чтобы от неё отказываться (не на сервере, а именно на том самом десктопе с файлопомойкой)?

Это «дофига», если у тебя всего 500гб есть. А когда у тебя есть 20тб то это незначительная мелочь. Потом у тебя будет 1000тб и мелочью будет потратить 20тб на оверхеды. Когда-то давно, когда были дискеты меньше мегабайта, даже 100кб потерять никто бы не захотел. А сейчас?

Страйпы в большинстве случаев - либо некомпетентность, либо злонамеренное вредительство. Намного лучше смонтировать эти диски отдельно и разложить по ним файлы примерно поровну (и сразу, на случай дурацких возражений, уточню: руками это делать не надо, это должна делать та прога или скрипт, которая управляет содержимым этого хранилища).

В комментариях вроде пытались давать оценки, но как-то неубедительно.

Какое ещё «пытались»? Посмотри /etc/mke2fs.conf, inode_ratio=16384. Ну или ключом -i можно сменить.

2% от 20TB - это примерно 400GB, на секундочку

Для 50 байтов это 1 байт. Если нет резерва задействованного системой, то система не сможет подменять сбойные кластеры из резерва.

Страйпы в большинстве случаев - либо некомпетентность, либо злонамеренное вредительство

Я на локалхосте использую страйпы на два диска, чтобы быстрее читать/писать большие файлы.

Например, чтобы экономить ресурс SSD, храню профиль firefox в виде tar.lz4 архива, который распаковывается на старте системы в tmpfs, а перед выключением — пакуется обратно на жесткий диск. Чтение/запись со страйпа раза в полтора быстрее, причем чем больше дисков, тем быстрее линейные чтение/запись.

btrfs

Как я понимаю для одного раздела никаких плюшек.

Если нет резерва задействованного системой, то система не сможет подменять сбойные кластеры из резерва

Резерв на уровне ФС совсем не для этого. А тут и вовсе 400 гигов бесполезными чексуммами забить предлагают. Да я лучше sha-1 или md5 рядом с каждым файлом положу для контроля битости.

Это очень редко проявляется где-то на практике. В частности, в твоём примере это влияет исключительно на такую несущественную ерунду, как время запуска и выключения системы, которые в норме случаются где-то раз в месяц. Даже если у тебя раз в день по старым обычаям, это всё равно ни на что не влияет.

И кстати, в порядке оффтопа, на ресурс ссд это вряд ли как-то существенно влияет. А ещё это означает что при аварийном ребуте профиль откатится. А ещё (уже в качестве плюса) - что ты можешь этот откат сделать вручную если случайно запорол профиль вр время работы.

профиль firefox в виде tar.lz4 архива, который распаковывается на старте системы в tmpfs, а перед выключением — пакуется обратно на жесткий диск.

Почему не mount overlay в tmpfs и rsync перед выключением? RAM будет меньше заниматься и записи на SSD, возможно, меньше.

профиль firefox в виде tar.lz4

Не понял в чём фишка? У меня профиль полтора гиг и сжимать/ разжимать для экономии чтения/записи так себе идея, тем более профиль не читается полностью, а только запрашиваемое ресурсом.

Резерв на уровне ФС совсем не для этого.

Гугл пишет, что резерв для удобной работы контроллера.

А на уровне фс, что там за резерв кроме базы данных файловой системы, её копии и потери в кластерах?

Гугл пишет

Не надо на гугл заходить, это плохой сайт.

Резерв для того, чтобы если глупые юзеры забьют весь диск своим мусором, у рута всё равно оставалось доступное для использования место.

Только вот занятые 389ГБ у автора это не резерв а метаданные. Резерв занятым не считается.

Не надо на гугл заходить

Чем же он плох, не думаю, что кому то информация с космоса прямо в голову подается, проверенная на истинность высшими силами.

Резерв для того, чтобы если глупые юзеры забьют весь диск своим мусором, у рута всё равно оставалось доступное для использования место.

Такое действительно существует? Какой то линукс обновлял, нехватало места, так система еле шевелилась, когда я пытался принять меры

Такое действительно существует? Какой то линукс обновлял, нехватало места, так система еле шевелилась, когда я пытался принять меры

Существует, но практическая ценность спорная. Это может предотвратить падение запущенного от рута сервиса на сервере, когда кто-то под пользователем совершит ошибку и забьет место. Но и сервис от рута должен крутиться, и ошибка должна быть из под пользователя. Чаще всего это неучтенные 5% места, про которые просто забыли.

389G — это дофига.

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

Например, xfs и ext4.

У ext4 раздел после форматирования будет меньшего рзамера, но не это самое интересное. Вот так выглядит чистый раздел ~1tb (без доп. опций при форматировании, только отключил резервирование места на ext4):

• Размер раздела: 960303848

• Занято: 2076

• Свободно: 960285388

• 16384 потерялись

Размер раздела зависит от числа inode и за счет манипуляции ими можно увеличить его на ~0.5-1.5% на здоровом разделе с крупными данными. Потерянное место - журнал.

У xfs:

• Размер раздела: 976285628

• Занято: 18727104

• Свободно: 957558524

• Занятое и свободное место точно соответствует размеру раздела (который при этом больше)

У xfs служебные данные просто отображаются как занятое место. Разница в свободном месте ~0.2%, а не ~2%, как может показаться если смотреть на занятое.

Практический тест с копированием 9,5M png:

• На xfs влезло 99326 файлов (30m 31s)

• На ext4 влезло 99613 (35m 4s на копирование). Из интересного, последние пару сотен файлов писал с заиканиями, будто бы что-то на диске подчищал. Занято 99626 из 60955350 инодов, т.е. понимая примерно тип хранимых файлов можно запросто до 1% места на этом сэкономить.

• На btrfs влезло 100887 (32m 43s). Btrfs был примонтирован с нефорсированным сжатием zstd с уровнем по умолчанию, хотя при тестированиях на png-шках ни один байт на сжатии не отыграть. Просто нет практического смысла не использовать сжатие на любых дисках под файло, оно либо не оказывает влияние, либо какие-нибудь файлы таки под него попадут.

• С btrfs ~1.5% больше xfs, на ~1,2% больше ext4.

• С ext4 при более-менее разумным ограничением по инодам для медиа диска такого размера (-i 10000000) велзло 101193. На ~0.3% больше btrfs и на ~1.5% больше дефолта ext4. Дальше профит от ограничение инодов минимальный, а риски упереться в них растут существенно.

Тратить это место на чексуммы для торрентовой мультимедиа на локалхосте — расточительство.

Это особенность отображения служебных данных в df при использовании xfs. А чексуммы там для журнала и занимают они копейки, нет смысла их трогать.

внезапных отрубаний питания и ядерных паник

при этом повалится только ФС. структуры самого лвм меняются очень редко и транзакционно - при фейле транзакция просто откатится.

попробуй отформатировать раздел в ext4 с параметрами -m 0 и -N 1000000

мильён инодов на видосики и музыку более чем достаточно

Другими словами: проблемы с проверенной временем ext4 действительно настолько велики, чтобы от неё отказываться (не на сервере, а именно на том самом десктопе с файлопомойкой)?

Скорее у ext4 просто нет достоинств перед альтернативами в подавляющем большинстве ситуаций. Когда по какой-то причине нежелательно использовать btrfs/zfs, тогда есть xfs, в которой есть рефлинки, не надо думать об инодах, не надо ждать долгий fsck при проблемах по питанию, так и еще работает чаще всего шустрее.

xfs, в которой есть рефлинки

применительно к данным ТС они ведь бесполезны ?

применительно к данным ТС они ведь бесполезны ?

Так и есть, только зачем ext4 использовать? Ради интереса тест провел и как оказалось, что в btrfs даже с несжимаемыми данными и их чексуммами влазит больше, быстрее, и только ужавшись по инодам ext4 может отыграть ~0.3%.

Так и есть, только зачем ext4 использовать?

я бы использовал ext4 т.к. более с ней «знаком» по опыту обычного использования, возможно сейчас и с xfs/btrfs/xfat все нормально и нет повода беспокоится

На xfs влезло 99326 файлов (30m 31s)

Без рефлинков 99932, на ~0.6% больше всего. Они вполне могут оказаться полезны на таком диске и отключать ради этого сомнительная затея.

Обычная gpt разметка, один физический раздел без всяких LVM извращений. Ну и ФС - ntfs. Читаться будет везде и во всех ОС. Для домашней файлопомойки лучше не придумать.

ntfs

Я об этом подумал при условии, что это вытаскиваемый диск. А если это просто диск в его системе, то проще в том формате, в котором его система.

первое, что пришло в голову — это xfs

ext4:

• по разным тестам не хуже или не сильно хуже работает с крупными файлами;
• лучше работает с мелкими файлами - а это в твоём случае могут быть эскизы, плейлисты, субтитры, торрент-файлы;
• ест меньше ресурсов;
• лучше переносит внезапное отключение.

И вообще зачем тебе эффективно работать с большими файлами? Ты собираешься с диска на диск терабайты копировать или просто кинчик смотреть?

А может вообще лучше lvm?

Видимо, тебе не помешает.

Для «один раздел» никакая разметка не нужна.

Для «один раздел» никакая разметка не нужна.

А проблем с совместимостью не будет? Если накатить файловую систему прямо на диск без разметки, то все ОС это поймут?

Так и есть, только зачем ext4 использовать?

Относительная простота, и как прямое следствие - надёжность и ремонтопригодность. Нужны гораздо более весомые основания чтобы даже начинать смотреть по сторонам чем высосанное из пальца «а вдруг иноды кончатся?!».

Оффтоп разумеется не поймёт, но я бы не стал на эту тему переживать. Остальные поймут, монтирование делается по имени устройства, просто пишешь не /dev/sdc1 а /dev/sdc

Не лучшее решение, выравнивание страдает.

выравнивание страдает.

Это как?? С этим подходом много проблем, но уж точно не выравнивание…

Т.е. что «как» ? Пробовал так делать, parted ругался, что раздел не выравнен и это скажется на производительности. Забил так такой подход, счас везде /dev/sdX1.

Пробовал так делать, parted ругался

А, ну тогда понятно… Трудно нулевым офсетом выравнивание заскрюапить, не надо верить всему что на заборах пишут.

т.е. parted верить не надо?

Никаких разделов parted не должен был увидеть, т.к. их просто нет - ФС ведь сразу на диске без всяких разделов.

Так про какой-такой раздел ругался parted?

т.е. parted верить не надо?

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

Да, чё-то попутал, но какая-то прога ругалась.

Короче, это было давно. Какая прога ругалась не помню. Поэтому до сих пор применяю трационный способ.

Поэтому до сих пор применяю трационный способ.

И правильно делаете. Плюсы наличия этой таблички с лихвой перевешивают все минусы, даже с одним разделом.

Нужно ext4 форматировать с отключенной функцией resize_inode -O ^resize_inode, оно много места отъедает.

multimedia

«а куда бекапить 20TB, и что в принципе делать если оно крякнет?»

думаю, не перевелись еще сиды в торрентах

чо там бэкапить-то

Нужно ext4 форматировать с отключенной функцией resize_inode -O ^resize_inode, оно много места отъедает.

Хм, без отключения влезло 99613, с -O ^resize_inode 99621.

Снапшоты, сжатие

Чего? В торрентах же встроенная проверка чексумм