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

Btrfs для всего.

Если линукс то ext4 и не выпендривайся.

Быстрый гуглинг показал, что если я откажусь от crc и reflink, то все станет намного лучше.

Если тебя так беспокоят занятые 2% объёма то сходи к психологу что ли.

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

Нет.

Если линукс то ext4 и не выпендривайся.

+1

Если тебя так беспокоят занятые 2% объёма

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

Если линукс то ext4 и не выпендривайся.

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

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

Да у него в логе это и написано, он скорее всего увидел 389G занятых и ужаснулся. Но тут следует в обратную сторону думать: 389G для 20T тома - это всего лишь незначительные 2%, забить. А когда-нить будет 500TB том и 10TB занятого на накладные расходы, оно всё так же окажется незначительной мелочью, если учитывать общий масштаб.

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

Что-то мне подсказывает на разделе с multimedia проблемой это даже близко не будет. Меня бы больше волновало «а куда бекапить 20TB, и что в принципе делать если оно крякнет?» (а рано или поздно оно таки крякнет).

Чтобы истратить все иноды на дефолтном ext4 надо чтобы средний размер файла был меньше 16кб. Впрочем, с позиции лишней траты места тут есть о чём беспокоиться: столько инод «разделу с мультимедиа» явно не нужно, они впустую тратят диск, хоть и не сильно, надо понизить их количество при mkfs.

Вот crc, который ты собрался отключать, я бы ценил больше чем динамические иноды. А ещё насчёт xfs тут ходили слухи что оно при аварийных ребутах любит жёстко рассыпаться, впрочем у меня обратный опыт: сделал клон диска с xfs с помощью dd на работающем сервере базы (dd не атомарное и совершенно неконсистентное), и с этого клона удалось, после xfs-ного аналога fsck, запустить систему как будто у неё всё хорошо.

насчёт xfs тут ходили слухи что оно при аварийных ребутах любит жёстко рассыпаться

Есть такое: xfs действительно куда как более чувствительна к аварийным остановам чем ext4. И доставать с неё данные после аварий куда как более геморройно. В домашних условиях я бы xfs ни для чего что «дорого сердцу» использовать не стал бы.

Есть такое: xfs действительно куда как более чувствительна к аварийным остановам чем ext4.

Нет такого. У меня лично с ext4 были проблемы после внезапного отключения электричества, с xfs, тьфу-тьфу, - ни разу.

LVM + XFS – нормальный вариант. firkax не слушай, у него бзик на LVM почему-то. Логики нет, одни эмоции. Много раз ему о плюсах талдычили, без толку. LVM – промышленный стандарт.

нужно перенести разделы на другой сервер (комментарий)

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

ТС выше писал открытым текстом, что еще дисков позже может добавить. С голой ФС или классическими разделами собрать тот же RAID того или иного типа сложнее будет, например.

Невредимая ФС еще не означает невредимых данных внутри БД.

И при помощи твоего нелюбимого LVM можно было добавить новый диск как PV в VG и смигрячить LV на новый диск на лету – если у тебя была задача перевезти ОС или данные на новый диск.

ext4.

btrfs мне норм

# btrfs filesystem usage /mnt/storage 
Overall:
    Device size:                  16.37TiB
    Device allocated:              5.94TiB
    Device unallocated:           10.43TiB
    Device missing:                  0.00B
    Device slack:                    0.00B
    Used:                          5.89TiB
    Free (estimated):             10.44TiB      (min: 5.23TiB)
    Free (statfs, df):            10.44TiB
    Data ratio:                       1.00
    Metadata ratio:                   2.00
    Global reserve:              512.00MiB      (used: 0.00B)
    Multiple profiles:                  no

Data,single: Size:5.88TiB, Used:5.87TiB (99.77%)
   /dev/sda1       5.88TiB

Metadata,DUP: Size:30.00GiB, Used:10.67GiB (35.58%)
   /dev/sda1      60.00GiB

System,DUP: Size:64.00MiB, Used:688.00KiB (1.05%)
   /dev/sda1     128.00MiB

Unallocated:
   /dev/sda1      10.43TiB

В следующем году может еще винт возьму чтобы зеркало замонстрячить.

Нет такого.

А вот у меня были. Причём на боевом серверном железе. Так что YMMV.

ext4 на lvm, конечно же. Гибко и надёжно.

Про иноды смешно, у меня rdiff-backup хомяка не истратил и 8% инодов. Их число можно уменьшить при форматировании, но это не стоит мозговых усилий.

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

Хорошая ФС ровно одна - ZFS,

Лог большой был?

В случае 20 Тб инод будет много. В случае 20гб - бало.

По умолчанию число инодов в ext4 зависит от размера ФС, в случае ФС небольшого размера при ее создании нужно указывать ключ для задания числа инодес.

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

Но у автора 389 Гб это много, не понятно почему столько, даже с учётом 20 Тб размера ФС.

Сам использую xfs часто, 20 Тб нет, но 6 Тб есть и там размер служебных данных после создания ФС не превышает 0.001% от ее объема.

Аналогично на CEPH кластере размер 4 Тб из 8 OSD, метаданные - примерно 400 мб.

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

Хотя lvm я использую. И не только её.

ntfs уже предлагали?

Много ли я теряю?

С другими ты потеряешь ещё больше, за исключением разве что fat/exfat.

Быстрый гуглинг показал, что если я откажусь от crc и reflink, то все станет намного лучше.

Formatting a filesystem without CRCs selects the V4 format, which is deprecated and will be removed from upstream in September 2030. Distributors may choose to withdraw support for the V4 format earlier than this date.

От рефлинков для мультимедийных данных в принципе можно было бы отказаться[*], особенно если ФС лежит на HDD, но я не знаю, сэкономит ли это что-нибудь без отказа от CRC

[*] Если их не предполагается систематически редактировать — тогда дуликаты файлов можно безболезненно заменять на симлинки, и рефлинки не понадобятся

Да, это пожалуй единственная ситуация, когда без LVM и прочих наворотов лучше – стандартная разметка + ext4 лучше для восстановления данных.

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

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

Ну всякое бывает, но 600тыс инодов это как-то мало, там фс видимо была крохотная.

Невредимая ФС еще не означает невредимых данных внутри БД.

Согласен.

И при помощи твоего нелюбимого LVM можно было добавить новый диск как PV в VG и смигрячить LV на новый диск на лету

LVM там тоже был, кстати. А ещё можно было вместо dd использовать xfsdump+xfsrestore, создав перед этим вручную все эти lvm-абстракции, разделы и файловые системы. Но я сделал тупо dd на весь диск чтобы не возиться с этим всем и обойтиись одной командой.

если у тебя была задача перевезти ОС или данные на новый диск.

Нет, разумеется, у меня была задача кое что проверить в той системе но не трогая работающий прод (ну кроме чтения). А побочно я решил, кроме собственно экономии времени на вводе всяких команд, поразвлекаться проверкой насколько выживет xfs после такого варварства. Вот и вышло что всё получилось успешно. Мигрировать систему таким способом я бы конечно не стал.

В случае 20 Тб инод будет много. В случае 20гб - бало.

Инод и там и там будет дефолтно примерно size/16384.

в случае ФС небольшого размера при ее создании нужно указывать ключ для задания числа инодес.

Никак нет. Указывать ключ надо если ожидается хранение слишком мелких файлов. Если средний размер файлов больше 16кб - всё будет норм на фс любого размера. Если меньше - иноды закончатся, опять же на фс любого размера.

Так у автора и есть домашнее использование.

Не соглашусь. Аппаратный рейд или программный в первую очередь обеспечивает большую доступность данных, позволяет получить больший объем хранилища.

Т.е. если в RAID, без разницы аппаратном или программном выходит из строя диск или начинаются проблемы с записью / чтением - контроллер его помечает сбойным и удаляет из массива. Далее если его просто заменить и запустить процесс перестройки - возникает повышенный риск, что следом за вышедшим из строя диском от интенсивной нагрузки при пересчёте контрольных сумм, репликации данных при перестройке массива следом выйдет из строя ещё один диск. И все, массив развалился полностью.

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

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

В случае выхода диска в RAID массиве из строя, правильный подход: прочитать все данные с него.

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

А старые положить на полку.

Не соглашусь, опять повторюсь, что в моей практике на ext4 размером примерно 20 Гб, при создании файловой системы просто через mkfs.ext4 /dev/sdXY закончились иноды при хранении дерева portage.

На ext4 большего размера такой проблемы нет.

Да и просто, если создать ext4 на контейнерах разного размера и сравнить вывод df -i после монтирования можно увидеть, что число блоков inode разное и зависит от размера ФС.

Upd:

Инод и там и там будет дефолтно примерно size/16384.

Ну так ты же сам и пишешь, что число inodes зависит от размера ФС. В чем тогда смысл комментария?

Чем меньше ФС - тем меньше число inodes и без пересоздания ext4 увеличить нельзя.

Не соглашусь, опять повторюсь, что в моей практике на ext4 размером примерно 20 Гб, при создании файловой системы просто через mkfs.ext4 /dev/sdXY закончились иноды при хранении дерева portage.

Там должно было быть примерно 1200000 инод. Вероятно, в дереве portage файлов больше и они все чрезвычайно мелкие, о чём я и писал.

что число блоков inode разное и зависит от размера ФС.

Конечно зависит, читай лучше что я писал.

В чем тогда смысл комментария?

В том что количество инод само по себе - число бесполезное, важна их плотность. Если ты 20ТБ диск заьёшь кучей клонов своего portage то, вероятно, иноды там кончатся тоже раньше чем место. Повторю - надо смотреть средний размер файла а не тупо количество.

Я одно время наигрался с разными ФС, сейчас ext4, везде.

20 терабайт? Это не домашнее, это уже ИП минимум.

С чего это? Время идёт, средние объёмы накопителей растут. Лично мне домой 20ТБ, конечно, не надо, но даже на ЛОРе я время от времени встречаю заявления что много терабайт домой это почти необходимость.

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

Далее если его просто заменить и запустить процесс перестройки - возникает повышенный риск, что следом за вышедшим из строя диском от интенсивной нагрузки при пересчёте контрольных сумм, репликации данных при перестройке массива следом выйдет из строя ещё один диск. И все, массив развалился полностью.

Поэтому нужны СРК, что делают бекапы по расписанию и резервные ноды, да.

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

В случае выхода диска в RAID массиве из строя, правильный подход: прочитать все данные с него.

Если для RAID 1 или там 10 это имеет ещё смысл, то для RAID5 или 6 уже полная ахинея выйдет.

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

А старые положить на полку.

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

Если для RAID 1 или там 10 это имеет ещё смысл, то для RAID5 или 6 уже полная ахинея выйдет.

Аналогично и даже больше вероятность.

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

Это уже нюансы управления и инфраструктуры.

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

20 Тб объём данных за выходные перельётся.

(а рано или поздно оно таки крякнет).

До того, как оно крякнет, обычно приходится покупать новый более объёмный HDD, потому что на старый файлопомойка уже не помещается. Вот на освободившиеся старые HDD и бекапить.

Ахинея в том смысле, что попытки восстановить данные с одного диска из RAID1 возможны, то с RAID5 или 6 – там каша без прочих дисков.

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

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

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

А ты предлагаешь превентивно делать даунтайм, причем долгий.

Обычно такие даунтаймы допустимы лишь ради чего-то некритичного, для чего и риск развала RAID приемлем, особенно если есть копии в СРК.

Беспокоиться об инодах нужно, когда много маленьких файлов (текстовых с парой строк). Мультимедия к таким случаям не относится.