История изменений

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

Видишь ли, в чем проблема... Ты никогда не можешь быть уверен, что записалось на диск, а что не записалось, если это не 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 лет назад просто не сравнить. В остальном же, повторюсь, вопрос веры.

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

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

Алиса на машине с общим объемом ОЗУ пишет большущий файл на 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 лет назад просто не сравнить. В остальном же, повторюсь, вопрос веры.