Здравствуйте, andrey.desman, Вы писали:
vsb>>2. Гарантированная целостность ФС при нормально работающем оборудовании и потере питания без длительных проверок при загрузке.
AD>Современные журналируемые ФС не требуют проверок вообще.
NTFS, Ext4 требуют. Хотя это, конечно, не современные ФС а ужас из 80-х.
vsb>>Также контроль целостности файлов и метаданных даже при сбоящем оборудовании (контрольные суммы).
AD>Контрольные суммы в ФС — это в принципе смешно, но для файлов еще смешнее.
AD>Разработчики IPv6, например, подумали, что козе баян не нужен и контрольные суммы из пакетов убрали, т.к. есть контрольные суммы уровнем ниже, а так же есть контроль данных на уровне приложения.
AD>Здесь ситуация та же — жесткие диски и ссд сами хранят ECC для каждого сектора/страницы и могут прочитать лишь то, что было когда-то записано, либо не прочитать ничего вообще.
AD>В этом смысле идея о контрольных сумм для файлов (со стороны ФС) выглядит дико, т.к. если делать эти суммы блоками фиксированной длинны, то они уже есть в железе, а если делать их для всего файла, то дозапись одного мегабайта в файл 10Г заставит страдать пользователя в страшных муках. Если же речь о транзакционности, то таким похвастаться могут только лог-фс, но они для общего случая не годятся, работают нормально только на ссд и требуют постоянной сборки мусора / дефрагментации.
Контрольные суммы конечно же для блоков. И, как я уже писал, в реальном мире устройства хранения не всегда работают так, как тебе хочется. Если ты уверен в своём оборудовании (например как Apple), тогда без проблем. Для универсальной ФС это неприемлемо, это как предполагать, что электричество никогда не отрубят, ведь любой нормальный компьютер защищён ИБП, а в любой нормальной операционной системе нет багов и она никогда не зависнет. И ИБП не всегда срабатывает, даже если он есть и операционные системы виснут и диски возвращают мусор.
Тут статья про APFS от разработчика ZFS и он специально акцентирует:
The Apple folks were quite interested in my experience with regard to bit rot (aging data silently losing integrity) and other device errors. I've seen many instances where devices raised no error but ZFS (correctly) detected corrupted data. Apple has some of the most stringent device qualification tests for its vendors; I trust that they really do procure the best components. Apple engineers I spoke with claimed that bit rot was not a problem for users of their devices, but if your software can't detect errors then you have no idea how your devices really perform in the field. ZFS has found data corruption on multi-million dollar storage arrays; I would be surprised if it didn't find errors coming from TLC (i.e. the cheapest) NAND chips in some of Apple's devices. Recall the (fairly) recent brouhaha regarding storage problems in the high-capacity iPhone 6. At least some of Apple's devices have been imperfect.
As someone who has data he cares about on a Mac, who has seen data lost from HFS, and who knows that even expensive, enterprise-grade equipment can lose data, I would gladly sacrifice 16 bytes per 4KB—less than 1% of my device's size.
vsb>>3. Абстракция от хранилищ, множество разделов, raw-разделы, мгновенное изменение размера любого раздела. Т.е. поставил я новый хард на 4 ТБ в компьютер, добавил его в пул, поменял размер /home на +4ТБ и всё, при этом все операции моментальные.
AD>Не понятно, зачем все это делать на уровне фс, если на отдельном уровне вроде llvm получается и гибче, и проще?
LVM это часть системы управления файлами и хранилищами. Можно из разделить на разные уровни, можно на одном. Мне больше нравится подход, когда один инструмент используется для всего.
А почему LVM гибче и проще? По-мне как раз таки всё наоборот. Чтобы изменить размер раздела в LVM, мне как минимум надо сделать две операции — изменить размер физического раздела и потом изменить размер файловой системы (при этом куча файловых систем это или не позволяют делать или позволяют делать только в одну сторону), в ZFS, например, раздел с файлами это одна сущность и меняется одной командой.
vsb>>6. Поддержка RAID (т.е. RAID должен быть реализован в ФС, не на другом уровне).
AD>Зачем именно на уровне ФС? Смысл городить комбайн?
Например идёт перестройка массива. У меня раздел на 4 ТБ, в нём лежит 500 GB файлов, остальное пустое место. Файловая система знает, где данные, а где мусор, соответственно будет копировать только данные. Уровнем ниже уже этого знания нет, поэтому восстановление будет для данного случая идти в 8 раз дольше.
vsb>>7. Поддержка быстрых кеширующих хранилищ, например небольшой быстрый SSD перед большими HDD, естественно полностью прозрачно для пользователя.
AD>Опять же, зачем это на уровне ФС?
В целом мне без разницы, я не считаю LVM не уровнем ФС, для меня это часть настройки, т.е. будет это ZFS или LVM+XFS, без разницы. ZFS гораздо удобней в использовании, чем LVM, но в целом задачи решаются приблизительно одинаковые и разница невелика.
