Re: nilfs vs. btrfs vs. ...
On 06/29/17 22:10, Ivan Shmakov wrote: > > Так же я понимаю, что никакие снапшоты не дадут в моих условиях > > полной гарантии консистентности, > > Боюсь, что не вполне понял оные условия. Использование snapshot > (не важно — Btrfs, Nilfs, или LVM — под журналирующей ФС) > сохраняет «мгновенное» состояние ФС — после чего с этого > состояния можно снимать резервную копию сколь угодно долго. Я имел в виду, что "мгновенное" состояние совершенно не обязательно содержит консистентные данные. Оно гарантирует, что в нем есть только полностью записанные блоки (и нет ни следа еще не закончивших писаться), но не факт, что уже записанные и попавшие в снапшот данные не зависят от еще не записанных и не попавших. Полную консистентность обеспечит только штатная остановка софта на время бэкапа (или наличие специальной ручки "записать в отдельное место полностью консистентные предназначенные для бэкапа данные", как в некоторых СУБД), но мне лень это делать каждый день. :) За информацию спасибо, буду думать дальше.
nilfs vs. btrfs vs. ...
> Alex Kicelewwrites: [Опять странности с рассылкой?] […] > Вопрос: увеличит ли вероятность восстановления консистентных данных > переход на файловую систему с встроенными снапшотами Такую вероятность увеличит даже использование «внешних» (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
Validation failed
*** Errors validating /srv/www.debian.org/www/international/l10n/po/en_CA.ru.html: *** Line 183, character 374: "128513" is not a character number in the document character set *** Errors validating /srv/www.debian.org/www/international/l10n/po/en_GB.ru.html: *** Line 118, character 351: "128513" is not a character number in the document character set Line 311, character 337: "128513" is not a character number in the document character set Line 1289, character 241: "128513" is not a character number in the document character set -- You received this mail for the language code ru. Please edit webwml/english/devel/website/validation.data if this is not accurate Please also update webwml/english/devel/website/ with the new coordinator(s) data
Re: Стратегия поддержания резервных копий. Деградация носителей.
On Mon, 26 Jun 2017, Oleksandr Gavenko wrote: OG>Или поступать как с лентами - попеременно между лентами гонять данные, что бы OG>освежать намагниченность? badblocks -n ?
fs в узком определении
Hi Есть домашний ноут с одним винтом (не ssd), "разбитым" на один партишн. Он ежедневно бэкапится (наживую, даже без остановки каких-либо программ) на подключаемый на время бэкапа внешний винт ручным запуском самописного скрипта (вызывающего внутри себя кучку rdiff-backup). Наличие бэкапа уже неоднократно выручало после совершенных мною же неверных правок и/или удалений отдельных файлов. Необходимости восстанавливаться с бэкапа после смерти винта пока что не было -- винты, конечно, мерли, но постепенно, позволяя скопировать информацию на новый прямо со старого. Плановых проверок восстанавливаемости тоже не производилось (по причине лени и шибкой муторности процесса), поэтому у меня нет никаких гарантий, что если, не дай бог, винт таки помрет сразу весь, то с этого бэкапа удастся полностью восстановить все (имеются в виду только /home и /etc, /usr не бэкапится вообще, /var частично бэкапится, но в основном не для восстановления, а чтобы в случае необходимости можно было бы туда поглядеть глазами). Разумеется, риски подобного образа жизни я понимаю, он был выбран сознательно. Вопрос: увеличит ли вероятность восстановления консистентных данных переход на файловую систему с встроенными снапшотами (кошусь на nilfs, ибо если я правильно понимаю (в том числе и благодаря чтению недавно пролетевшего треда про zfs), она хуже zfs/btrfs только отсутствием сжатия на лету (и, возможно, дедупликации, реальная необходимость которой в моих условиях близка к нулю), а остальные возможности zfs/btrfs для меня являются оверкиллом, ибо никаких рейдов на ноуте с одним гнездом для винта нет и не предвидится), или же оверхед от использования такой фс (в качестве единственного, т.е. в том числе и рутового, партишна) будет более заметен на глаз, чем гипотетически более корректное восстановление? Под оверхедом я имею в виду как технический (общее замедление работы за счет copy-on-write, бОльшая требовательность к памяти и процу и пр.), так и "моральный" (в основном надежность -- насколько я понимаю, zfs для линукса существует только в юзерспейсе, а присутствующие в ядре nilfs и btrfs не настолько отлажены (а возможно, и не доделаны) сами по себе). Так же я понимаю, что никакие снапшоты не дадут в моих условиях полной гарантии консистентности, речь лишь о вероятности. Но не хватает данных и знаний, чтобы прикинуть, стоит ли овчинка выделки, или только морока одна?
Re: Маршрутизатор Debian Jessie с ядром из backports: не работает pptp через NAT
Anton Gorlovписал(а) в своём письме Wed, 28 Jun 2017 23:28:28 +0300: 28.06.2017 11:13, Михаил Касаджиков пишет: Это дело стало необходимым потому что то ли в свежих ядрах, то ли в дебиане (давно копал) теперь nat_helpers не применяются без явного на то указания. В ядрах..Вернее в таблесах автомат сделали депрекейтед. Тогда точно нужно переходить на правила в iptables. -- Написано с помощью почтового клиента Opera: http://www.opera.com/mail/