nilfs vs. btrfs vs. ...
>>>>> Alex Kicelew <arkoort@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
Reply to: