Несколько дней назад забавы ради вкатил на ноут c Intel(R) Atom(TM) CPU Z520 @ 1.33GHz поверх dm-crypt, посмотреть как дела. Сильнее подтормаживает в сравнении с ext4, эвристика сжатия всё так же хромает: compress-force=lzo даёт заметно лучшее сжатие чем автомат. Сейчас смонтировано с просто compress.
По стабильности этому до ext4, как пешком до другой галактики, тут к гадалке не ходи.
А чего там настраивать-то? При установке арча монтируешь нужные тебе разделы в something-fs-name и радуешься Если нужно, то доустанавливаешь модули для работы нужной фс.
Например форматировать с --metadata single, т.к. старый (или подключённый через USB) SSD не определится как таковой и все метаданные продублируются. Т.к. btrfs пакует мелкие файлы в прямо в дерево, как reiser, можно слегка удивиться, когда окажется что метаданные заняли не просто 2Гб, а 2Гб дважды.
Например монтировать с noatime, потому что на ФС с COW это очень дорогая операция.
Во сколько раз отличается по часам на раздел общая наработка ext4 и btrfs? В 100 раз? В 1000? Твоё мнение: где больше багов есть вероятность найти и исправить, в коде который наработал 1000 или 1000000 часов?
Что умеет многодисковые хранилища на дисках разной ёмкости?
Без понятия. Но ext4 не умеет, а сравнивается с ext4, из чего я сделал вывод, что ТС, равно как и мне совершенно не нужны многодисковые хранилища на дисках разной ёмкости.
Возможно гдето не прав, но ИМХО CRC в ФС в текущей ситуации не интересно совсем. У нас и так CRC на уровне железа в накопителе есть десятилетиями, там bit rot будет сразу обнаружен и по возможности исправлен. А в самом уязвимом месте, ОЗУ, в потребительском сегменте нет нихрена.
Был период, когда AMD расщедрилось на ECC для десктопного железа, но потом стухло.
Имеем ситуацию, где поиск и коррекция ошибок есть, пока данные летят по сети, и от i/o контроллера до самой записи. А посередине нет ничего. И толку от переимплементации CRC там, где она уже обеспечена железом?
Лучше не настраивать btrfs. Мало смысла в ней. Жалкая пародия на zfs.
Подскажи, когда там на zfs наконец появится дефрагментация, переупаковка metaslab'ов, ресайз вниз, рестрайп? Когда она перестанет катастрофически деградировать при заполнении >60-70%? Подсказка: никогда.
Отменяет. Какой прок от обнаружения, о котором ты никогда не узнаешь? Контроллер может отправить тот мусор, который есть. Даже в энтерпразйном диске, просто потому что прошивку диска писали индусы. Или контроллера. Btrfs и ZFS обнаруживают, рапортуют и исправляют (если есть избыточность).
Потому что на старте продаж писали, что ECC именно что кукурузное.
Не кукурузное, просто производители материнских плат экономят на дорожках. В результате они говорят «ECC in non-ECC mode».
Какой прок от обнаружения, о котором ты никогда не узнаешь?
Почему не узнаю? Будет ошибка чтения, рост Offline Uncorrectable, запись в SMART Log.
В энтерпрайзе может и имеет смысл не доверять всей цепочке от контроллера до диска. Но у них то самое слабое место прикрыто.
А тут плывёт себе такой SOHO титаник, у которого на правом борту уже есть система обнаружения дырок от айсбергов, и тут капитану приходит в голову: о, а давай я на правый борт ещё вторую приварю. Ну приварил, молодец. А слева он, как и раньше, даже столкновения с Антарктидой не заметит.
Подскажи, когда там на zfs наконец появится дефрагментация, переупаковка metaslab'ов, ресайз вниз, рестрайп? Когда она перестанет катастрофически деградировать при заполнении >60-70%?
Поделись, пожалуйста, своим опытом, как ты этого добился. А то у меня уже все пулы на 98% полны, а деградация за столько лет (с 2009 года) так и не наступила.
Если вам нужно сжатие и снимки, btrfs, если надежность ext4
По скорости они похожи и у той и у другой есть способы оптимизации
Я перепробовал много fs, но вернулся к ext4, она оказалась тупо быстрее с дефолтными настройками и проще в восстановлении. Также надо смотреть как ведет себя fs при отключении питания
Уже, наверное, год сижу на BTRFS. Сжатие не использую, ибо у меня большой SSD и мне и так норм. Брат жив, ФС ни разу не сыпалась, производительность полностью устраивает.