> Не спорю что сбитие автомобилем вертолета круто, но практическая польза в чем?Отказ девайса это всё же немного другая ситуация, когда точно известно что данные там-то -- больше недоступны. И тогда даже raid5 как в mdraid справляется. Если данные битфлипнуты, raid5 их в принципе не сможет восстановить, а raid6 смог бы (если флипнулось только на 1 девайсе из N+2), но он этого не делает в принципе (я тоже проверял).
С другой стороны, я почитал старые крики btrfs-девелоперов о том что мол 'checksum on a checksum' (касательно хеша на блоки чётности) и то что они этого не сделали, потом посмотрел, что в openZFS всё чётко и изобрёл такой вот тест как в предыдущих мессагах описывал. Если openZFS выдюжило, то у меня 100% уверенность, что и любой случайный битфлип оно обнаружит и исправит. btrfs ниасилило -- ну значит и любой случайный битфлип может ниасилить, как раз из-за того, что не всё записанное на дисках рейда отхешено.
> 2) eatmydata apt dist-upgrade ... or whatever. И шел бы fsync нафиг!
Вот уже начинаются пляски с бубном :) (и это с учётом ещё того, что тот самый dist-upgrade в виртуалке пофрагментирует образ вхлам). А openZFS искаропки синхронные записи выполняет быстро -- у неё маленький кусок диска под линейный лог зарезервирован -- как раз быстро флашить синхронные записи подряд, чтоб диск бошками не ездил отписывая новую версию дерева каждый раз. В btrfs, говорят, тоже такой лог есть, но факт остаётся фактом -- там было *МЕДЛЕННО*.
> Зато менеджмент всего этого становтся просто адищем.
Если имеется в виду менеджмент снапшотов то в openZFS он да, немного геморный, но только лишь потому, что они решили абстрагироваться от простой модели vfs->mountpoints. Тем не менее, в btrfs например сделать снапшот геморойнее, надо зачем-то корень монтировать (если в обычном состоянии замаунчены только сабвольюмы).
> Я качал торенты и в зависимости от преаллокации, размера частей,
Во1 насколько я понял, преаллокации в btrfs как таковой нет, т.е. она может делать sparse файлы конечно же, но заранее место и положение на диске для последующей записи не резервирует в принципе.
Во2, не очень понял про кеш торрент-клиента, какой бы он ни был по размеру, если он кратно меньше чем весь качаемый торрент, то совпадений (когда будут иметься 2 соседних блока) будет пренебрежимо мало, и он всё равно будет вынужден отписывать данные в файлы рандомно. И тут-то бтрфс и рассыпется на тысячи фрагментов, причём если в торренте много файлов, то кол-во фрагментов, репортируемых filefrag раза в 2 больше оказывается, чем кусков торрента. autodefrag хорошо помогает для файлов типа логов, которые часто и по-чутьчуть дописываются, видно как сначала 4к кусочек добавился, потом ещё 4к, потом десяток последних кусочков по 4к рраз -- и в один запакованный кусок по 2-3 блока упихали. А вот на торрентах, особенно многофайловых, он примерно никак.
> Собссно btrfs fscrypt не сделал еще и потому
Я вот как-то на тот фскрипт пытался смотреть, и понял что без бутылки я там не разберусь. Даже какая-то утилита на go нашлась, которая его позволяет чуть проще менеджить. В то же время менеджмент шифрованных датасетов в openZFS примерно на уровне сложности luks -- ввёл пароль/ключ и оно появилось, вынес ключ -- обратно исчезло. Даже проще luksа, там ещё поверх расшифрованного псевдодевайса надо маунтить-размаунчивать, а openZFS само. Жаль что в btrfs не пошли таким же путём как в openZFS, а связались с fscrypt.
> А он это не чекает?
Проблема была в том, что если шифрованный пустой датасет создать на дестинейшене руками, то в него незашифрованный литься откажется, а если создавать вместе с началом заливки, то там были какие-то нетривиальные проблемы с указанием ключа, которые пришлось шаманить нетривиальными способами. После создания уже диффы новых снапшотов вливаются на ура и без проблем (надо только "расшифровать" датасет на дестинейшене перед вливом при помощи ввода пароля).
