https://ns.opennet.dev/openforum/vsluhforumID3/77748.html Разработчики проекта NEXT3 (http://next3.sourceforge.net/), в рамках которого уже несколько лет развивается неофициальная реализация поддержки мгновенных снимков состояния файловой системы Ext3 (снапшотов), представили (http://permalink.gmane.org/gmane.comp.file-systems.ext4/25968) первый выпуск набора патчей ext4-snapshots (https://github.com/amir73il/ext4-snapshots/), обеспечивающих работу снапшотов в файловой системе Ext4. <br><br><br>Вопрос об интеграции представленного набора патчей в Linux-ядро пока не решен. Набор состоит из 36 патчей и интегрируется с Ext4 через систему стандартных хуков. Предусмотрена возможность монтирования разделов с отключением поддержки снапшотов, в этом случае код никак себя не проявляет и ФС Ext4 функционирует как раньше. В качестве причины развития проекта указано желание интегрировать возможность работы со снапшотами в уже зарекомендовавшую себя и повсеместно используемую ФС Ext4, вместо использования экспериментальной ФС Btrfs или системы dm_multisnap (ht...<br><br>URL: http://permali https://ns.opennet.dev/openforum/vsluhforumID3/77748.html#90 Thu, 21 Sep 2023 20:36:30 GMT Зачем общий функционал выносить в отдельную программу, пускай каждый пишет свой велосипед заново.<br>Есть LVM, LUKS они хорошо работают, почему btrfs пилят свой велосипед? тем более не все виды рейда, в отличие от lvm, не поддерживают?<br>с ZFS ещё понятно оно в другой os родилось, но btrfs?<br> https://ns.opennet.dev/openforum/vsluhforumID3/77748.html#89 Tue, 11 Dec 2012 19:07:40 GMT &gt; конечно.<br>&gt; ведь снимки в btrfs это обычный subvolume.<br>&gt; с любого снимка (rw-снимка и снимка root ессесно имеется в виду) можно <br>&gt; просто загрузиться и дальше работать. всё, вот и весь откат.<br>&gt; тут до этого даже zfs далеко.<br><br>Чего "далеко"?<br><br>Концепция "снимок файловой системы или тома" никак не может быть "rw", так как это &#8212; ЗАМОРОЖЕННОЕ состояние файловой системы. Его можно только читать. Чтобы на его основе получить образ живой файловой системы, снимок надо клонировать. Тогда появляется возможность читать и писать в клоне. ZFS всем этим обладает. А Btrfs что предлагает, концепцию клонирования томов под соусом снимков?<br><br><br> https://ns.opennet.dev/openforum/vsluhforumID3/77748.html#88 Tue, 11 Dec 2012 09:33:33 GMT конечно.<br>ведь снимки в btrfs это обычный subvolume.<br>с любого снимка (rw-снимка и снимка root ессесно имеется в виду) можно просто загрузиться и дальше работать. всё, вот и весь откат.<br>тут до этого даже zfs далеко.<br> https://ns.opennet.dev/openforum/vsluhforumID3/77748.html#86 Wed, 15 Jun 2011 16:49:31 GMT &gt; Однако, <br>&gt; меня устроит и 99.9% данных с диска особенно если бэкапа не было или он старый.<br><br>Почти всегда при ликвидации fsck-ом повреждений файловой системы происходит частичная потеря информации. <br>Класно бы звучало:<br>Я:<br> - у меня сверхнадежная файловая система, проверка четности на лету, raidz3, +2 диска в hotspare <br>Fsck:<br> - е-е-е, тут это, малость данные подрежденны и я не знаю насколько это серьезно, примаунтить вроде можно, но что там за внутри твориться - четрт его знает <br>Я:<br>-ладно и так сойдет :)<br>Через два месяца оказывается что самый нужный файл таки битый.<br>Я:<br>- так, где там мой бекап старый, а я его уже затер новым бекапом, думая что там 99.9% нормальные, а оказалось только 99.8999% из них нормальные.<br>Вопрос: что вы будете делать с этой fs после того как востановили на 99.9% и знаете что там уже по ней беды пробежались. Продолжать пользоваться? <br><br>&gt;&gt; Концепция fsck - это востановления из журналов и прочее при ресете OS и <br>&gt;&gt; всяких нештатных ситуациях, <br>&gt;Например, fsck возможен на неж https://ns.opennet.dev/openforum/vsluhforumID3/77748.html#85 Wed, 15 Jun 2011 15:47:23 GMT А вы даже не способны прочитать то о чемь мы спорим. Если включить проверку данных в ext4 то получим такой же тормоз как и zfs. Причем тут ваш заумный коментарий?<br><br> https://ns.opennet.dev/openforum/vsluhforumID3/77748.html#84 Tue, 14 Jun 2011 20:43:56 GMT Хорошо, но от LVM не откажусь. Кроме снапшотов там есть и более вкусные плюшки. А вот использовать преимущества LVM и Ext4 буду и далее, вместе они позволяют очень гибко управлять дисковым пространством.<br> https://ns.opennet.dev/openforum/vsluhforumID3/77748.html#83 Mon, 13 Jun 2011 07:32:11 GMT &gt;&gt; ах да, ещё в LVM нельзя сделать консистентный снапшот смонтированной в rw <br>&gt;&gt; файловой системы <br>&gt; Почему все ламерские заявления пытаются косить под истину в последней инстанции?<br><br>Наверное потому, что авторы этих заявлений, в отличие от вас, понимают, что снапшот на уровне менеджера томов не может никаким образом учитывать состояние хранимой на нем ФС ?<br> https://ns.opennet.dev/openforum/vsluhforumID3/77748.html#82 Sun, 12 Jun 2011 21:08:00 GMT Все это говорит о том что запасной парашют в виде fsck - это не опциональный аксессуар, а суровая необходимость в реальных ситуациях. <br> https://ns.opennet.dev/openforum/vsluhforumID3/77748.html#81 Sun, 12 Jun 2011 21:01:04 GMT Вы оказались неспособны осознать что CoW и журнал - это одно и то же, просто в разной реализации. Утрируя, CoW - это такая журналирующая ФС, где область данных ликвидирована, а вместо нее область журнала расширена на весь диск. Это единственное концептуальное отличие. Все что оно этим достигает - раз области данных нет, не надо переносить ("коммитить") журнальные записи в область основной ФС. Это просто логичная оптимизация журналирования. <br>