Хотя вот (redhat.com) RedHat рекомендует XFS.

У меня XFS на разделе в несколько терабайт не падала за последние лет 5 (может больше). Резкие потери питания бывали. Кроме того, пишут, что старые болячки XFS (типа просера данных при резком выключении) большей частью вылечили. Стоит попробовать, особенно если есть бэкапы.

ок

reiser

Сам то её используешь на серваках?

Какой период времени?

Чем ext4 не устраивает ?

С юности отпугивает проблема с inodes, это на правах шутки.

Если серьёзно, может и устроит, я просто не знаю как хорошо, она «переварит» накопитель такого размера :-)

В RHEL макс. для ext4 это 16ТБ. Потом будешь мигрировать на xfs. Оно тебе надо? Ставь сразу xfs

У всех фс производительность на уровне. Гораздо важнее функционал

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

Если много текстовых файлов имеет смысл фс со сжатием типа btrfs

Говорят jfs за счет примитивности сверхнадежна, правда когда я ее испытывал она почемуто обрезала недописанные файлы, возможно изза примитивности журналирования

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

Да, я смотрю, что по очкам пока xfs выигрывает.

Тем более, это виртуалка снепшоты/бэкапы будут под рукой все время.

Без задачи и контекста трудно сказать что-то определенное. Вопрос из серии «посоветуйте дистр».

Почитайте тут, хотя бы.

тред не читай @ сразу отвечай!

Файловая система для раздела большого размера (комментарий)

Задача - почтовик на Зимбре с обвесами.

Вроде заказчик созрел.

Ограничение в 16 ТБ весомый аргумент против ext4 .

https://access.redhat.com/solutions/1532

Certified and [maximum] file system size

Далее, тестим на тестовом полигоне красношапки fedora 32:

# lvcreate -n ext4size -V 17T --thinpool pool0 fedora
  WARNING: Sum of all thin volume sizes (20,45 TiB) exceeds the size of thin pool fedora/pool0 and the size of whole volume group (7,39 TiB).
  Logical volume "ext4size" created
# mkfs.ext4 -E lazy_itable_init=0,lazy_journal_init=0 -L ext4_17TiB /dev/fedora/ext4size
mke2fs 1.45.5 (07-Jan-2020)
Discarding device blocks:  done                            
Creating filesystem with 4563402752 4k blocks and 285212672 inodes
Filesystem UUID: 7ea9acb9-fc65-4203-ac80-ad110b2de7a9
Superblock backups stored on blocks: 
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
        4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
        102400000, 214990848, 512000000, 550731776, 644972544, 1934917632, 
        2560000000, 3855122432

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (262144 blocks): done
Writing superblocks and filesystem accounting information: done         

# mkdir /mnt/ext4size
# mount /dev/fedora/ext4size /mnt/ext4size
# df -h /mnt/ext4size
Файловая система            Размер Использовано  Дост Использовано% Cмонтировано в
/dev/mapper/fedora-ext4size    17T          24K   17T            1% /mnt/ext4size

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

UPD:

# lvresize --resizefs -L50T /dev/fedora/ext4size
fsck из util-linux 2.35.2
ext4_17TiB: 11/285212672 files (0.0% non-contiguous), 18420895/4563402752 blocks
  WARNING: Sum of all thin volume sizes (53,45 TiB) exceeds the size of thin pool fedora/pool0 and the size of whole volume group (7,39 TiB).
  Size of logical volume fedora/ext4size changed from 17,00 TiB (4456448 extents) to 50,00 TiB (13107200 extents).
  Logical volume fedora/ext4size successfully resized.
resize2fs 1.45.5 (07-Jan-2020)
Resizing the filesystem on /dev/mapper/fedora-ext4size to 13421772800 (4k) blocks.
The filesystem on /dev/mapper/fedora-ext4size is now 13421772800 (4k) blocks long.

# mount /dev/fedora/ext4size /mnt/ext4size
# df -h /mnt/ext4size
Файловая система            Размер Использовано  Дост Использовано% Cмонтировано в
/dev/mapper/fedora-ext4size    50T          24K   48T            1% /mnt/ext4size

Инодов стало 838860800.

В любом случае, это ведь LVM поверх ext4 ?

Наоборот. На диске лежит lvm, на lvm лежит ext4. Но это не важно же, на свойства ФС подложка не влияет.

Да, ошибся)

Интересная инфа.

Тогда любая подойдет.

Ограничение в 16 ТБ

Его нет.

Раньше было такое, когда еще ext4 не было, зато система была неубиваема от слова совсем

Это лимит размера одного файлика, а диски она до 1EiB

А зачем Вам ФС? Это будет только явной прослойкой.

Отдавайте логический том напрямую в ВМ.

Отдавайте логический том напрямую в ВМ.

Можно подробнее, что конкретно Вы имеете ввиду?

Тут плюс в том, что ВМ можно снэпшотить/бэкапить в хранилище гипервизора.

Затем и прослойка.

[sdb] - > [pv]-[vg]-[lv] -> [raw in VM] 
                     |
                     |____[snapshot]    

К примеру, так. Хотите мгновенный снапшот? Сделайте снапшот LVM, а потом делайте с ним то, что захотите. К примеру, загрузите его на ваш сервер бэкапов и удалите LVM-снапшот

в хранилище гипервизора.

https://wiki.qemu.org/Features/Snapshots

Мне такой вариант не нравится.

а в дебианоподобных? где про эти лимиты посмотреть в системе?

ok, я вообще-то планировал Proxmox ставить нативно на ZFS.

Надо будет глянуть подойдёт ли Ваш вариант в таком случае.

ZFS

</thread>

В РХЕЛ это лимит ФС (mkfs.ext4 не сделает больше 16ТБ)

Сейчас уточнил это до RHEL6, в 7 и 8 увеличили до 50Т

Certified and [maximum] file system size
File system 	RHEL 3 	RHEL 4 	RHEL 5 	RHEL 6 	RHEL 7 	RHEL 8
Ext2/3   	1TiB    2TiB    16TiB 	16TiB 	16TiB 	16TiB
Ext4  		n/a 	n/a 	16TiB 	16TiB	50TiB  	50TiB
XFS3 		n/a 	n/a 	100TiB 	300TiB 	500TiB 	1PiB

ZFS будет на хосте, на ВМ хочется чего-то попроще или, что ты предлагаешь?

Или просвети меня как можно сделать репликацию диска на ZFS на другой накопитель по уму.

Т.е. без гипервизора сверху)

репликацию диска на ZFS на другой накопитель по уму.

zfs send/zfs receive ?

А каковы плюсы/минусы этого решения по сравнению с ВМ?

Да, я зациклился)

Ведь, вероятно, Proxmox под капотом делает тоже самое?

В reiserfs синхронное обновление метаданных, а они содержат в себе списки всех блоков, потому что экстентов там нет. На больших директориях или больших файлах reiserfs будет заметно тормознее ext4, потому что выполняет кучу ненужной работы.

Раньше размеры разделов и размеры файлов были заметно меньше, поэтому этот недостаток не проявлялся.

А каков плюс крокодила по сравнению с бутербродом?

Может ты хочешь сравнить zfs send/zfs receive с чем-то конкретным... ну я не знаю, со снапшотами ВМ. Или с чем-то еще...

Я пока что не понял какая у тебя задача(то что в ОП-посте - это общие требования, а не задача). Возможно сказывается то, что уже конец рабочего дня и голова у меня уже не варит :-/

Хорошо, начнём с целеполагания)

Мне нужна отказоустойчивость.

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

Proxmox, по крайней мере, может мне обеспечить синхронную репликацию между 2-мя нодами.

А что я могу сделать, если поставлю Zimbr’у на голое железо и буду делать zfs send/receive на другой сервак?

Видимо, ничего.

Пока решил остановиться на XFS, а там видно будет.

Пока читаю истории

XFS! Оно спецом и создавалось для больших файлов.

reiser

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

ZFS

Ынтырпрайзно и тормознуто. То, что нужно!

Говорят jfs за счет примитивности сверхнадежна

Врут.

Отдавайте логический том напрямую в ВМ.

Вот прям +1

Согласен, зато при куче мелких файлов она быстрее ехт4

пока не совсем заброшено, и да для кучи мелких и неубиваема от слова «совсем» сам ты неуч! звезд набрал а ума и воспитания null!

А что я могу сделать, если поставлю Zimbr’у на голое железо и буду делать zfs send/receive на другой сервак?

Эм... ну не знаю. Переткнешь кабель в новый сервер и поехали?

Но если нужна виртуализация, то конечно да, лучше Proxmox