Прозрачное сжатие EXT4/Отговорите от BTRFS/Поток сознания

и я не понял, включится ли оно или нет, если потом в опции монтирования добавить.

Нет, и более того, отключить это потом будет никак нельзя, т. к. атрибут nodatasum наследуется от каталогов к файлам:

All files created under nodatasum inherit the «no checksums» property, however there’s no corresponding file attribute (see chattr(1)).

Так что я бы оставил чексуммы.

Подозревал. Спасибо, этого я в доках не начитал.

Снёс 400 гигабайт, конвертнул, всё хорошо. Убил снапшот предыдущей ФС и запустил ребаланс... Стал ловить 12309. Ладно, хрен с ним, но тут выпал разъем питания. Система загрузилась, всё хорошо - запустил scrub - оно нашло один повреждённый файл. Файл журнала systemd. Запустил ребаланс снова, правда, ФС уже подмонтировалась с compress=zstd - ловлю 12309 при заполнении writeback в bcache. Если так и дальше пойдёт - мне не нравится. А я ещё дефраг хотел сделать. Может после ребаланса и дефрага получу то, что хотел.

Забивание гвоздей микроскопом. btrfs – система с кучей тонкостей, о которых даже в документации не написано.

Для того, чтобы организовать прозрачное сжатие, проще всего использовать VDO. Громоздить ради этого btrfs – оверкилл и большой риск.

BTRFS может сдохнуть от power save.

Вообще – файловая система должна быть максимально простой. Права определяются разделами. Делаешь /home чисто для себя. Вместо фс открываешь /dev/sdx как файл и используешь. Нужно всего-лишь запомнить смещения на каждый файл. Вероятность отказа стремится к нулю.

BTRFS может сдохнуть от power save

сдохнуть может всё.

Для того, чтобы организовать прозрачное сжатие, проще всего использовать VDO. Громоздить ради этого btrfs – оверкилл и большой риск.

Насмешил. Вот уж где будут костыли, так это с VDO.

Вместо фс открываешь /dev/sdx как файл и используешь. Нужно всего-лишь запомнить смещения на каждый файл.

Угу. Особенно если файл был 1 мегабайт, а через 2 года стал 100 гигабайт. Самому не смешно?

По теме - ребаланс оборвался опять потерей питания. Перезапустил - остановился на битом файле. Сделал scrub - опять побился журнал systemd. Прибил файл, запустил ребаланс, решил оставить бук часа на 3 - работать невозможно с 12309. До дефрага дело еще даже не дошло.

BTRFS может сдохнуть от power save

сдохнуть может всё.

Нет не всё. BTRFS.

P.S.: лично меня парит, что с n+1-ым патчем ядра, когда туда подвезут контроль над батарейкой в сраный ASUS и всё заработает у меня отвалится жёсткий.

Это уже поправили, если ты не знал.

Интересный тред. Поглядим на результаты.

Отговорите от BTRFS

BTRFS может сдохнуть от power save

Это уже поправили, если ты не знал.

Mission failed.

Битый — это checksum error?

Как так вообще может быть, если системд отключает COW на своих журналах?

Прибил файл, запустил ребаланс, решил оставить бук часа на 3 - работать невозможно с 12309. До дефрага дело еще даже не дошло

Попробуй без bcache, или перевести его в режим writethrough.

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

Если это не абсолютное исключение, то, наверняка, уже доступен тест, чтобы определить это?

Битый — это checksum error?

Именно.

Как так вообще может быть, если системд отключает COW на своих журналах?

Значит в манжаре не отключает. Я вообще этого б не знал, если б ты не сказал. Кстати, журнальчики то как раз те, что писались во время потери питания, так что может и не COW.

Попробуй без bcache

Ну вот вырубить bcache это дополнительные телодвижения - мне надо будет сдвигать начало раздела на 8 кило, править fstab, регенерировать initramfs и т.п. Пока понаблюдаю.

или перевести его в режим writethrough.

Гхм. Это сделает ребаланс просто недостижимым по времени, скорость чтения/записи с этого винта падает до 10-12 метров в секунду, а ребаланс меня удивляет, о наблюдениях ниже.

Теперь, собственно, остальные набллюдения.
1. bcache стал работать эффективнее. Как кэш у меня используется SSD на 240 гиг, поэтому самое нужное вполне может влезть на SSD. В связи с тем, что винт медленный я вырубил к чертовой бабушке sequential_cutoff - в общем-то, иначе кэш набирается очень медленно, но с бэтром стало всё несколько, гхм, быстрее. Не знаю, с чем связано, но на ext4 не любое чтение приводило к попаданию данных в кэш, в моих условиях это было несколько не желательно.
2. В связи с вышеизложенным, ребаланс мне ушатал 2% жизни SSD (сам в шоке).
3. Сделал дефраг - во время дефрага было записано в 1,5 больше данных, чем есть на диске (смотрел через iotop -a -d 1).

После дефрага было так:

Data, single: total=276.47GiB, used=232.54GiB

Залил часть данных, стало так:

Data, single: total=298.35GiB, used=296.63GiB

Не понятно. Больше дефрагментировать пока не собираюсь.

Ребаланс был прерван перезагрузкой, висел на одном чанке из 450. ПОсле ребута продолжение быстро (за пару секунд) выполнило ребаланс 3 чанков и на этом успокоилось. Делаю вывод, что отображение прогресса в утилите сделано криво (хрен бы с ним, но подозревается, что ребаланс до конца не завершился).

Сегодня опять выпал шнур питания, но уже в процессе нормальной работы. Сделал scrub - ошибок не нашлось. Почему-то мне кажется, что файлы бились именно из-за потери питания во время ребаланса. На ext4, справедливости ради, метаданные тоже бились в таких случаях, но не сильно и не смертельно - грешу на железо и связку с bcache (у SSD большой DRAM и, вероятно, он под высоким I/O не флушит его содержимое когда надо) - поэтому несоответствие чексум с файлами, с которыми была активная работа считаю логичным.

В остальном, вроде бы, система чувствует себя нормально, при больших дисковых I/O ведёт себя вполне вменяемо. Продолжаю заливать данные, ребаланс даже не уверен, буду ли выполнять. В любом случае, отложу до выходных, когда можно будет ноут поставить на пару дней шуршать. Сейчас заливаю данные назад, посмотрю, насколько поможет и поможет ли.

наверняка, уже доступен тест, чтобы определить это?

Видишь ли, в чем проблема... Ты никогда не можешь быть уверен, что записалось на диск, а что не записалось, если это не RAID с батарейкой. Фишка заключается в том, что алгоритмы, по которым железо отрабатывает барьеры знает только вендор, и они могут оочень сильно различаться. Тест он простой как палка - пишем на диск данные, в разных режимах и разными количествами и дергаем питание, а потом смотрим, что записалось, а что - нет. Как ты понимаешь, практически ни один диск без суперконденсаторов не способен корректно сбросить все данные при отключении питания - это ясно и без всяких тестов. И когда железка не нагружена - да черт бы с ним, она наверняка успеет отработать всю запись, а если что-то не отработает - это будет крайне мало. А если будут большие объемы ОЗУ/большие буферы/потеря питания, то происходит следующее.

Алиса на машине с общим объемом ОЗУ 32 Гбайт пишет большущий файл на HDD. Используется промежуточное writeback-кэширование на SSD. Железо ни разу не энтерпрайз, а самый что ни на есть десктопный ширпотреб (Гнусмасы EVO к тому же ширпотребу относятся, если вдруг чего). Так вот, если произойдет внезапная потеря питания - Алиса при дефолтных настройках потеряет:
1. Примерно 6,5 гигабайт содержимого файла + журналы ФС за последние 10-30 секунд - из-за writeback в оперативку.
2. 512-2048 мегабайт данных из-за DRAM-буфера в SSD. Они могут содержать и журналы ФС, и бог знает что ещё.
3. 8-256 мегабайт буфера HDD (тоже самое).

Обычно система выполняет sync после записи критичной порции данных. Но сначала SSD отрапортует о нормальной записи после получения данных в DRAM и ДО фактической записи в ячейки. Потом драйвер, который перекладывает данные из SSD на HDD считает эти данные (а они могут быть ещё и не записаны) и отправит на запись в HDD. И о, странность: HDD тоже отрапортует об успешной записи данных ДО того, как он начнёт их писать на пластины - в это время они лежат в буфере.

Для предотвращения подобных ситуаций, в общем-то, используются журналы, а CoW должен оказаться и ещё надёжнее тащем-та (пока метаданные не побьются). При монтировании файловых систем в этом случае сначала будет проверен журнал на HDD и будут откачены все начавшиеся, но не законченные транзакции - данные на HDD придут в консистентное состояние. После будет просмотрен журнал на SSD, откачены начавшиеся, но не завершенные транзакции, сверена последняя транзакция, которая должна быть записана на HDD с фактически записанной и если что не так - откат происходит на SSD. Это слой bcache. Потом подрубается слой файловой системы и уже откатывается транзакция, которая была не закончена в результате потери данных в RAM.

Теперь, какие преимущества даёт CoW:
Дело в том, что запись может выполняться в файл, и этот файл не смотря на откат транзакции своё содержимое в классическом случае откатить не может. Т.е. он вроде бы и целый, а внутри него - мусор. В случае же с CoW - пока транзакция не завершится, старое содержимое файла доступно и никуда не девается, отсюда мы при необходимости отката транзакции не только приведём в порядок метаданные, но и восстановим консистентное состояние непосредственно данных на момент перед сбоем.

Так что сам по себе btrfs чисто теоретически даже устойчивее классических файловых систем должен быть, но и на старуху бывает проруха: это могут быть баги в коде (не говорите, что в классических ФС их нет), так и приколы с железом.

Из плюсов, что мне понравилось - так это то, что благодаря scrub я теперь точно знаю, какие данные были побиты после проблем с питанием/внезапного резета. В случае с ext это было попросту невозможно. Преимущества CoW (теоретические, а не данной конкретной реализации) я расписал выше. ПОнравилось сжатие на лету (не разобрался пока до конца с выводимыми данными утилит), вожможность снепшотов (не всем надо, но оно есть), ну и оверкилл фичи, которые мне пока не нужны - это RAID, объединение нескольких физических устройств в одно, онлайн-изменение размера). Из минусов - сильная фрагментация (для чего мне нужен bcache), большой объем метаданных и их не фиксированное положение (что делает значительно более сложным восстановление информации после полного краха). Ещё к минусам, пожалуй, можно отнести и необходимость использования отдельных утилит вместо привычных (btrfs filesystem df вместо df к примеру), но это мелочи.

Стабильность же непосредственно кода этой ФС это вопрос другой, а на сегодня больше вопрос веры, т.к. я видел и умершие безвозвратно Ext3/4, NTFS, XFS (эту сам лично убивал), FAT/exFAT, HPFS, JFS. То, что бэтр пилится и сейчас в состоянии, примерно соответствующем бете - меня устраивает (мне нужен стандартный сетап, а не кульбиты над пропастью): с тем, что было 5 лет назад просто не сравнить. В остальном же, повторюсь, вопрос веры.

Mission failed.

Естественно. Я знаю, что здесь есть люди, которые пользуются этой ФС, а есть и ярые противники этой ФС. Я рассчитывал, что в случае чего меня ткнут в _актуальные_ проблемы, но т.к. петух уже клюнул, пришлось ходить по граблям самому. Разочарования, как такового, нет - обнаружил несколько плюсов для себя, несколько минусов. В общем, как обычно. Теперь уже будут проблемы - буду кудахтать, какая эта ФС плохая.

ребаланс оборвался опять потерей питания

Ты какой-то эпичный ссзб. А сделать так, чтобы при конвертации фс питание не пропадало - никак?

А сделать так, чтобы при конвертации фс питание не пропадало - никак?

Ну, во-первых, ФС сконвертирована. Ребаланс это другое и нужен в обычном случае один раз в жизни или после добавления нового устройства в ФС. Во-вторых, про то, что я люблю БДСМ и садо-мазо, я писал ещё в первом посте. Я ЗАЕ%%%СЯ менять эти разъемы питания у этого делла, в связи с чем никогда не знаешь, какое шевеление оставит ноут без питания. Батарейка китайская тоже подохла внезапно и сразу. У местных батарейки с алика и с наценкой в полцены ноута, а китайцы пока что ничего не отправляют, поэтому аккум будет только через полгода, по всей видимости. Разъем питания в загашнике остался последний, и как-то менять пока старый относительно жив не хочется. А я люблю, когда система там что-то делает, поиграть/порнуху посмотреть/поработать, мне девайс постоянно бывает нужен, а не трогать его во время каких-то длительных фоновых процессов не считаю не целесообразным. Надеюсь, вопросы про питание отпадут.

P.S> бэкап ещё не понадобился, значит пока что всё делается правильно.

Ну у меня иногда в dmesg сыпало всяким красным. И ещё один раз после хард-ресета /home перемонтировался в ro, но я его перемонтировал обратно и не было проблем никаких. А теперь и dmesg молчит – после форматирования и переустановки ОС.

Ты же понимаешь, что меня интересует конкретитка.

Ты же понимаешь, что меня интересует конкретитка.

Возьми винт, переходник SATA-USB и в момент записи выдерни провод. Ну или то же на живом компе, что не так удобно.

P.S.: я кстати что-нибудь такое сделаю, но не скоро.

Угу. И зачем? Кстати, с огромной долей вероятности ничего не сломается. Но именно так я XFS убивал, так что мне не ясно, что ты от меня хочешь.

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

Ну да, у меня всё хорошо. Вот только твоих шифровок не понимаю.

Собственно, всё, эксперименты с ФС закончились. Сжатие на уровне 20% с zstd (много архивов, могло быть и больше), bcache стал эффективнее, в остальном ничего примечательного. Всё просто работает пока.

Только что в #bcache прилетело. Про барьеры.

after consulting with another fs developer i’ve come to the conclusion that some of the bug reports are likely to be because of drives that don’t handle fua correctly, bcache/bcachefs uses fua in a slightly unusual way and btrfs has been bitten by such drives too

Пока всё отлично. Правда, если запустить виртуалку и не отключить ее файлам cow случается тормоза, но тут уже by design. Отключил cow для нужных файлов и как бабка отшептала. Внезапные ребуты под нагрузкой переносит нормально, сжатие 30 процентов на моих данных, проц не грузит, память не жрет. Я пока доволен.