> А XFS умел в "убран менеджер томов", очень интересно.Умел, вырезали сказав что дублирование функций LVM не нужно. Но тут невелика потеря.
> Ого, перечислетите тех, кто умеет в "убрана поддержка блоков > 4K"
Эмм. Ну NТFS например умеет под виндой, поэтому под линуксом тоже пришлось поддерживать.
XFS на IRIX умеет блоки до 64К. А под линуксом это не работает, из man.xfs:
-b block_size_options
Section Name: [block]
This option specifies the fundamental block size of the
filesystem. The valid block_size_option is:
size=value
The filesystem block size is specified with a
value in bytes. The default value is 4096
bytes (4 KiB), the minimum is 512, and the
maximum is 65536 (64 KiB).
Although mkfs.xfs will accept any of these
values and create a valid filesystem, XFS on
Linux can only mount filesystems with pagesize
or smaller blocks.
> "фичи типа Guaranteed-rate I/O" - бред
Почему бред? Это для рилтаймовых систем, можно открыть поток чтения/записи, которому нужно гарантировать пропускную способность не менее такой-то (или несколько), и другие запросы на ввод/вывод на этот диск не смогут этим потокам помешать. Т.е. специализированный шедулер IO внутри ФС. Ничего страшного тут нет, в том же ZFS тоже свой шедулер внутри и ему стандартный линуксовый для блочных устройств только мешает (и она его отключает).
Но в линукс версию XFS это не вошло.
> "поддержка иерархии сторейджей" - офигеть, одна фс, один путь!
Ну что-то в линуксе это все пытаются переизобрести, то в btrfs никак не могут допилить, то костылями типа bcache, то вовсе работающих решений кроме как взять сомнительный по лицензии zfs нет..
Задача иметь tiered storage с быстрыми SSD первого уровня, медленными второго, жесткими дисками третьего например довольно много где встречается, и когда ФС ее умеет решать, это неплохо. А внешними средствами эффективность совсем не та выходит.
