отказоустойчивая фс

btrfs поверх luks

Тут противоречие

какая система на ssd будет более стойкой к внезапному отключению?

Ext4

Стоит выделить из директорий другие поддиректории, вроде /var, которые мне не нужны для снапшотов?

А они тебе точно не нужны? Тащемта, система может сломаться в нескольких случаях: прерванная установка и поврежденный /boot, что-то не так с базой данных пакетного менеджера и что-то с видеодровами.

Пакетные менеджеры, в основном, хранят свою базу в /var.

Тут противоречие

Это у тебя тут непонимание термина «отказоустойчивость».

Резонно. Наверное, стоит оставить его в / и делать снапшоты.

Подожди intelfx, он btrfs пользуется, в отличие от толпы советчиков из соседнего топика.

тоже иногда хочется такое. но не факт, что это оптимальнее делается на бтрфс. сейчас набегут регистранты, распишут тему и окажется, что на zol это получится реализовать лучше.

zfs? Я не видел примеров в мейнстримных дистрибутивах линукса, где бы применяли zfs для рабочих станций. Накатить-то можно, но будет ли смысл от использования без рейда на десктопе? Мне кажется btrfs как раз в таком случае повыгоднее.

Если я правильно понял, что он (btrfs) умеет и чем хорош, конечно*

Вынеси второй вопрос в отдельный топик.

У автора темы тоже непонимание отказоустойчивости, что ж такое-то.

Забудь всё, что тебе написали выше по треду

Думаю разбивать на такие разделы

Норм.

Дальше поверх luks сделать btrfs, который поделить на подтома

Я не рекомендую хранить какие-то данные в корневом подтоме. Его невозможно переименовать, переместить или удалить, поэтому ты поимеешь большой геморрой при попытке восстановления из снапшота. Создавай подтом типа /arch, /fedora, /ubuntu или что у тебя там стоит, и все остальные либо в нём (/arch/var/tmp), либо рядом (/home). Дальше разруливай точками монтирования.

Стоит выделить из директорий другие поддиректории, вроде /var, которые мне не нужны для снапшотов?

Эээ, /var тебе нужен в снапшоте. Иначе на его восстановление ты потратишь примерно столько же сил, сколько на переустановку системы с нуля.

Вроде загрузок в хомяке. Они только место на снапшоте будут занимать. Что вы обычно выделяете, чтобы не снапшотать лишнее?

/var/tmp, /var/log можно, кэш твоего пакетного менеджера, ~/.cache.

Еще не до конца понял (не уверен, что понял правильно), как работает btrfs снапшот. Когда делаю снапшот подтома появляется новый подтом, идентичный оригинальному, но он не монтируется, а остается в холодном резерве. Вся дельта пишется на оригинальный подтом. Если нужно что-то откатить, мне нужно отмонтировать оригинальный подтом, примонтировать снапшот этого подтома и удалить оригинальный. Все правильно?

Вообще работают они слегка через зад, но общая идея похожа на то, что ты описываешь. Когда ты делаешь снапшот, то в файловой системе создаётся новый подтом, идентичный заснапшотанному, по указанному тобой пути. Что ты с ним будешь делать — второй вопрос. При восстановлении можно переместить новый подтом на место старого; можно ничего не делать, а просто сделать btrfs set-default.

Но учти, что что вложенные подтома сами собой не переместятся в новый — то есть с точки зрения усилий при откате правильнее создавать все подтома с данными рядом с основным, и монтировать их в явном виде.

Вообще, подтом в btrfs — это всего лишь такой особенный каталог, который можно примонтировать.

Какие опции разумно использовать для десктопа с упором в первую очередь на надежность

Читай документацию и смотри сам. «С упором на надёжность» — это пустая фраза, она ничего по смыслу не значит.

Впрочем, в целом могу посоветовать такие: noatime,ssd,discard=async,space_cache=v2,compress=zstd:1. Про discard=async смотри ниже, ещё в ряде случаев полезно flushoncommit (тоже смотри ниже).

Trim я так понимаю у нормальных ssd хардварные и добавлять что-то в опции монтирования не стоит, тем более в связке с luks.

Нет, абсолютно неправильно понимаешь. TRIM — это когда файловая система сообщает SSD, что она не использует такие-то блоки и они могут свободно участвовать в wear leveling. «Хардварным» TRIM не может быть по определению.

Тебе нужно включить discard на уровне LUKS (cryptsetup open ... --allow-discards) и настроить discard на уровне файловой системы (либо по таймеру, либо -o discard=async). Если SSD дешёвый и/или ты не делаешь много записей, то можно по таймеру.

Если ты записываешь на диск часто и много (суммарный объём записей между двумя срабатываниями таймера близок к свободному месту на диске), то либо уменьшай интервал таймера, либо включай discard в реальном времени через опцию монтирования (это будет слегка медленнее работать, но SSD будет дольше жить).

Второй вопрос по поводу отказоустойчивой к перебоям с электричеством фс. Если нет возможности поставить перед устройством ибп, какая система на ssd будет более стойкой к внезапному отключению? Условия такие, что устройство периодически пишет, но в основном читает. Просто в ro загнать нельзя. Если что, это не то же самое устройство, на которое btrfs хочу поставить.

Любая современная ФС (журналируемая или copy-on-write) будет устойчива к потере питания при корректно работающем железе. В зависимости от того, что конкретно ты там делаешь, с btrfs ещё могу посоветовать опцию flushoncommit, если нужна строгая транзакционная семантика всех записей на диск.

Спасибо за подробные пояснения. Еще раз уточню по порядку восстановления бекапа, т.к. это для меня самый главный вопрос и причина попробовать btrfs. Кейс обновления пакетов с рутовым подтомом.

• Делаю снапшот рутового подтома.

• Ставлю обновления.

• Если что-то не работает из обновленного, демонтирую рутовый поддтом, монтирую снапшот. Рутовый могу удалять

Все так?

Ты не сможешь отмонтировать корневую ФС на живой системе. Либо (если корневая ФС монтируется с дефолтным снапшотом) делаешь снимку btrfs set-default, либо (если корневая ФС монтируется через -o subvol=/path) переименовываешь исходный корень в какое-нибудь временное название и переименовываешь снапшот в корень. После этого перезагружаешься и удаляешь старый корень.

В обоих случаях тебе нужно проследить, чтобы внутри старого корневого подтома не было вложенных — потому что снимки снапшотов в btrfs нерекурсивные. Также в обоих случаях для всех манипуляций тебе придётся завести вспомогательную точку монтирования, на которую ты будешь монтировать ФС с опцией -o subvol=/, чтобы видеть всё дерево подтомов, а не только тот, который у тебя на корне.

отказоустойчивая фс

Это не про btrfs. Глючное поделие. Львиная часть кода китайцами написана.