>>>>> Alex Kicelew <arko...@gmail.com> writes: [Опять странности с рассылкой?]
[…] > Вопрос: увеличит ли вероятность восстановления консистентных данных > переход на файловую систему с встроенными снапшотами Такую вероятность увеличит даже использование «внешних» (LVM) snapshots. (# lvcreate --snapshot ; e2fsck ; mount /mnt ; rsync /mnt /backup.) > (кошусь на nilfs, ибо если я правильно понимаю (в том числе и > благодаря чтению недавно пролетевшего треда про zfs), она хуже > zfs/btrfs только отсутствием сжатия на лету (и, возможно, > дедупликации, реальная необходимость которой в моих условиях близка к > нулю), а остальные возможности zfs/btrfs для меня являются > оверкиллом, ибо никаких рейдов на ноуте с одним гнездом для винта нет > и не предвидится), AIUI, в Btrfs на текущий момент вложено куда больше времени и сил разработчиков (и пользователей, пишущих отчеты о проблемах), чем в Nilfs. Как следствие, вероятность встретить доселе неизвестную проблему в случае Nilfs — выше. Я, к слову, сталкивался с проблемой ENOSPC при выполнении (IIRC) # apt-get upgrade на Nilfs. ISTR, что действующий в userspace GC не успевал вовремя «освободить» пространство, ранее занятое удаленными файлами. С Btrfs такого как будто бы не наблюдалось. (Впрочем, Btrfs я использовал образца 2016‒2017 гг., из Stretch; Nilfs — 2012.) > или же оверхед от использования такой фс (в качестве единственного, > т. е. в том числе и рутового, партишна) будет более заметен на глаз, > чем гипотетически более корректное восстановление? Под оверхедом я > имею в виду как технический (общее замедление работы за счет > copy-on-write, AFAICT, разница между write и copy-on-write зачастую сводится к обновлению еще одного-двух служебных блоков (extents tree для данного inode) в случае copy-on-write. Рискну предположить, что в подавляющем числе real world-сценариев, решающий (> 99%) вклад внесет запись собственно самих данных. Каких-либо формальных проверок я, однако, не проводил. > бОльшая требовательность к памяти и процу и пр.), так и «моральный» > (в основном надежность — насколько я понимаю, zfs для линукса > существует только в юзерспейсе, а присутствующие в ядре nilfs и btrfs > не настолько отлажены (а возможно, и не доделаны) сами по себе). Я использую Btrfs в каком-никаком production с февраля сего года (опять-таки, Debian Stretch.) Нарекания примерно следующие: • механизм квот Btrfs в многопользовательском окружении куда как легче приводит к проблемам, требующим вмешательства root, нежели «традиционные» квоты (не поддерживаемые Btrfs, увы); • отсутствует «штатное» ПО для дедупликации; можно использовать jdupes(1), или написать собственную обертку для FIDEDUPERANGE, но, на мой взгляд, проблема далека от решения; кроме того, я не нашел простых средств для диагностики (или, лучше, предотвращения) случаев, когда дедупликация приводит к /увеличению/ занимаемого пространства; (как следствие внесения расхождений в рабочую копию к одному или более snapshots); • в целом, userspace-инструментарий (и документация) могли бы быть полнее; особую тревогу, в частности, вызывает отсутствие штатного (off-line) fsck. OTOH, случаев потери данных или приведения системы в нерабочее состояние (kernel panic, etc.) мною пока замечено не было. И на том спасибо. > Так же я понимаю, что никакие снапшоты не дадут в моих условиях > полной гарантии консистентности, Боюсь, что не вполне понял оные условия. Использование snapshot (не важно — Btrfs, Nilfs, или LVM — под журналирующей ФС) сохраняет «мгновенное» состояние ФС — после чего с этого состояния можно снимать резервную копию сколь угодно долго. Да, для Btrfs есть механизм # btrfs send | (ssh) btrfs receive, который позволяет получить более точную копию (вместе со всеми метаданными — включая всяческие ACL и xattr, если в них вдруг появится необходимость), чем Rsync. В т. ч. инкрементально. Отмечу, однако, что лично я знаком с Ext2+ куда как лучше, поэтому применять Btrfs в качестве / (или иных «важных» ФС — кроме как, возможно, на «временных» виртуальных машинах) пока не рискую. Благо LVM позволяет, среди прочего, легко использовать произвольное количество ФС. > речь лишь о вероятности. Но не хватает данных и знаний, чтобы > прикинуть, стоит ли овчинка выделки, или только морока одна? -- FSF associate member #7257 np. Thanatos (BitLive2002 Anthem Edit) — DHS of TSW