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

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

Норм.

Дальше поверх 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, если нужна строгая транзакционная семантика всех записей на диск.

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

Норм.

Дальше поверх 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, если нужна строгая транзакционная семантика всех записей на диск.

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

Норм.

Дальше поверх 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.

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

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

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

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

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

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

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

Норм.

Дальше поверх 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.

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

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

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

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

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

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

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

Норм.

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

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

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

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

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

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

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

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

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

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

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

Впрочем, в целом могу посоветовать такие: noatime,ssd,discard=async,space_cache=v2,compress=zstd:1.

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

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

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

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

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

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