Разработчики проекта 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.
Вопрос об интеграции представленного набора патчей в Linux-ядро пока не решен. Набор состоит из 36 патчей и интегрируется с Ext4 через систему стандартных хуков. Предусмотрена возможность монтирования разделов с отключением поддержки снапшотов, в этом случае код никак себя не проявляет и ФС Ext4 функционирует как раньше. В качестве причины развития проекта указано желание интегрировать возможность работы со снапшотами в уже зарекомендовавшую себя и повсеместно используемую ФС Ext4, вместо использования экспериментальной ФС Btrfs или системы dm_multisnap (ht...URL: http://permalink.gmane.org/gmane.comp.file-systems.ext4/25968
Новость: http://www.opennet.dev/opennews/art.shtml?num=30826
Прикольно! Снапшоты удобны, когда имеется поддержка с пакетным менеджером, как в yum для btrfs - можно поставить что-то посмотреть, а потом быстренько откатиться.
А чем снимки в LVM не подходят?
они сильно сказываются на производительности, требуют выделения дополнительного пространства, причём если свободное место там исчерпается, будет не очень приятно. для кратковременного создания снапшота, чтобы снять бэкап, возможности lvm достаточны, для долгого хранения сразу нескольких снапшотов - нет.
>потом быстренько откатитьсяnext3 не имеет возможности отката, это главный её недостаток - тамошние снапшоты представлюятся в виде файлов-образов внутри текущего состояния фс, их можно монтировать через mount -o loop,ro -t ext2 . полагаю что в ext4-snapshots сделано также.
тогда они никак не могут стать заменой снимков из бтрфс
конечно.
ведь снимки в btrfs это обычный subvolume.
с любого снимка (rw-снимка и снимка root ессесно имеется в виду) можно просто загрузиться и дальше работать. всё, вот и весь откат.
тут до этого даже zfs далеко.
> конечно.
> ведь снимки в btrfs это обычный subvolume.
> с любого снимка (rw-снимка и снимка root ессесно имеется в виду) можно
> просто загрузиться и дальше работать. всё, вот и весь откат.
> тут до этого даже zfs далеко.Чего "далеко"?
Концепция "снимок файловой системы или тома" никак не может быть "rw", так как это — ЗАМОРОЖЕННОЕ состояние файловой системы. Его можно только читать. Чтобы на его основе получить образ живой файловой системы, снимок надо клонировать. Тогда появляется возможность читать и писать в клоне. ZFS всем этим обладает. А Btrfs что предлагает, концепцию клонирования томов под соусом снимков?
В целях повышения образованности: что это такое и какие приносит блага?
>В целях повышения образованности: что это такое и какие приносит блага?это возможность фс запоминать текущее состояние с возможностью в дальнейшем обращаться к нему. удобно для снятия бэкапов, кроме того сами по себе снапшоты можно использовать как бэкапы.
Например в можно сделать снапшот, поставить апдейты, понять что ничего не работает и просто вернуться назад без проблем. Можно открыть снапшот за вчера и достать файл, который только что случайно грохнул и т.п. При этом по ставнению с полным бэкапом ФС хранит только изменения файлов, а не копию файла на каждый день.
ext5???
Ещё не закончил конвертировать диск в ext4...
Скачал предкомпилированную версию. Забекаплюсь, буду тестить ;)
> Забекаплюсь, буду тестить ;)какой бекап, снапшот создай?!
> какой бекап, снапшот создай?!А если механика снапшотов облажается - он свои данные не просрет при этом случайно? :)
А LVM уже не православно?
Написано же, в чём преимущества снапшотов ext4 перед lvm'ными.
LVM не умеет подгонять размер снапшота под фактические нужды, Уйдёт снапшот за резервирование и всё. Едва ли такую убогую функциональность можно назвать юзабильной. Это ещё не говоря о скорости снапшотов в lvm
ах да, ещё в LVM нельзя сделать консистентный снапшот смонтированной в rw файловой системы
при создании снапшота lvm фс подготавливается к этому, если умеет (ext3, ext4, xfs умеют). впрочем, это нисколько не уменьшает других недостатков снапшотов lvm.
ну да, поддержка называется mount -o remount,ro. Очень круто.
>ну да, поддержка называется mount -o remount,roпогугли про bdev_freeze и хватит нести бред.
> ах да, ещё в LVM нельзя сделать консистентный снапшот смонтированной в rw
> файловой системыПочему все ламерские заявления пытаются косить под истину в последней инстанции?
>> ах да, ещё в LVM нельзя сделать консистентный снапшот смонтированной в rw
>> файловой системы
> Почему все ламерские заявления пытаются косить под истину в последней инстанции?Наверное потому, что авторы этих заявлений, в отличие от вас, понимают, что снапшот на уровне менеджера томов не может никаким образом учитывать состояние хранимой на нем ФС ?
> А LVM уже не православно?да отстой этот LVM, что вы с ним лезите.
Зачем общий функционал выносить в отдельную программу, пускай каждый пишет свой велосипед заново.
Есть LVM, LUKS они хорошо работают, почему btrfs пилят свой велосипед? тем более не все виды рейда, в отличие от lvm, не поддерживают?
с ZFS ещё понятно оно в другой os родилось, но btrfs?
http://thread.gmane.org/gmane.comp.file-systems.ext4/25968/f...Lukas Czerner(разраб. из RedHat'а): So it is true, when you have an fs problem (corruption) you have to blast off all your snapshots ?
Amir G.(разраб. снэпшотов из CTERA Networks): No, most of the time the problem could be solved by fsck -p without discarding snapshots. Only for the really hard cases, we had to discard the snapshots.
Стабильность, my ass
Что сказать то хотел?Разработчиков спросили: "а на сколько оно стабильно".
Ответили, что огромный плюс их подхода (по сравнению с снапшотами btrfs )в том, что старый fsck, десятками лет провереный на реальном боевом рабочем железе отработает как и раньше, то есть по крайней мере восстанавливаемость в случае сбоев не хуже чем голая ext3/4 по сравнению с btrfs. Единственное, что новый код, провереный только 2 года, каcается самих снапшотов. То есть, если железо сбойнуло и файловая система рухнула, даже если есть невыявленные еще ошибки в свежедобавляемом коде, всегда можно тупо удалить снапшоты и пройтись старым добрым fsck.
Никто не писал что новый код нестабилен или ТРЕБУЕТ удаления снапшотов для восстановления.
Короче, не позорь честное имя Анонимов.
Что не так? Снапшоты бакапы не отменяют. Или Вы не в курсе?
Они бы лучше утилиты допилили, а то срам.
> Они бы лучше утилиты допилили, а то срам.а что с ними не так?
> а что с ними не так?Max volume size 1 EiB (limited to 16TiB because of e2fsprogs limitation)
И кто то еще бочку катит на zfs с ее медленостю. Ясное дело что такая убогая фс как ext4 с таким убогим функционалом да еще с отключеным проверкой данных (только метадынные проверяются) будет априори быстрее zfs. Ну что же, комуто важна скорость в ущерб функционала. Даже не знал что ext4 снапшоты не поддерживает. Про клоны я вообще молчу o_O
А потом бравые бсдшники собирают свои ZFSные пулы чуть ли не хексэдитором. Чья бы мычала, с своими практически отсутствующими тулзами для восстановления тяжело разрушенной ФС. У EXTов их fsck по крайней мере до последнего пытается отколупать останки тома из того что получилось. А zfs при этом тихо умрет и восстановлению будет подлежать только хексэдитором разве что.
Вы путаете товарищ что то, если востановление этим вашим хваленых fsck не гарантирует 100% востановления файловой системы, а бед-блок когда там потеряны данные - это 100%-ов что ни о каких 100%-ах востановленых данных и речи быть не может. Концепция fsck - это востановления из журналов и прочее при ресете OS и всяких нештатных ситуациях, тоесть востановление структуры файловой системы, а не востановление бед-блоков. Бед-блок востановить невозможно, если нету бекапов либо raid1,raidz и так далее.
По крайней мере zfs файловая система и концепция CoW - это система которая гарантирует 100% сохранность данных и 100% консистентность данных при любых записях и четния данных (при ресетах при записи и прочее) но совершенно не гарантирует сохранность данных когда сама файловая система поврежденаа (будь то бед блоки и прочее). Для этого и существуют raid1/raidz/raid2z/raid3z и бекапы.
Глупо как то звучит - сверхнадежная файловая система, но при ее повреждении "пытается отколупать останки тома из того что получилось". :)
Какой смысл в fsck если он не гарантирует 100% востановление из бед-блоков для фс, которая позифионаруется как сверхнадежная?
восстановление и предотвращение появления бед-блоков -- это задача аппаратная а не фс. да и никакие рэйды не гарантируют 100% надёжности -- всегда есть вероятность что навернётся СРАЗУ ВСЁ!!1, например. а поскольку угробить фс значительно легче, чем получить бед-блок, постольку в условиях аварийных отключений именно возможность ЕЁ восстановления решает.
>восстановление и предотвращение появления бед-блоков -- это задача аппаратная а не фс.И вы тоже видимо не знакомы с концепцией zfs - недоверять никому кроме себя. В отличие от ext4/3/2 и все старых fs - доверять диску и контроллеру. Так что вы обсолютно не правы - для этого и делаются рейды1/raidz/raid2z/raid3z что бы востанавливать данные при появлении бед блоков - недоверять контроллеру и диску
> легче, чем получить бед-блок, постольку в условиях аварийных отключений именно возможность
> ЕЁ восстановления решает.Концепция CoW - при самый немыслимых аварийных отключения - фс ВСЕГДА 100% консистентна (мы тут не говорим об бед-блокак и повреждениях фс). В таком случае fsck ей не нужен. А про выковыревание битых данных с помощю fsck уже обсуждалось.
концепция -- хорошо, а на практике -- за последние два года в нашем грёбаном тьмутаракановске рабочая станция под xp + ntfs гробила фс 7 раз, почтовик-файлопомойка-роутер c free-bsd + zfs -- 1 раз, а радио-сервер/собиратор/компиляйтор/обогреватель с gentoo + ext3 -- 0 раз, бэд-блоков ни на одной машине не наблюдалось. по мне, это говорит гораздо больше, чем тонны концепций и прочих контрацепций.
Все это говорит лиш о том:
1) недостаточно статистики
2) любая концепция хоть как она не идеальна, реализовуется иногда с багами в софте, и далеко не идеальными руками.
:)
Все это говорит о том что запасной парашют в виде fsck - это не опциональный аксессуар, а суровая необходимость в реальных ситуациях.
> Вы путаете товарищ что то, если востановление этим вашим хваленых fsck не
> гарантирует 100% востановления файловой системы, а бед-блок когда там потеряны данные
> - это 100%-ов что ни о каких 100%-ах востановленых данных и речи быть не может.Разумеется, 100% данных если часть данных не читаема восстановить не удастся. Однако, меня устроит и 99.9% данных с диска особенно если бэкапа не было или он старый.
> Концепция fsck - это востановления из журналов и прочее при ресете OS и
> всяких нештатных ситуациях,Концепция fsck - это приведение файловой системы в консистентное, моунтабельное состояние. Из того что есть по факту. Например, fsck возможен на нежурналинуемом EXT2.
> тоесть востановление структуры файловой системы, а не востановление бед-блоков.
Восстановление и проверка структуры файловой системы. В том числе и после бэд блоков. Журналируемой ФС не нужен fsck при просто ребуте. В этом случае достаточно журнала.
> Бед-блок востановить невозможно, если нету бекапов либо raid1,raidz и так далее.
Бэд блок восстановить невозможно. Вот только если он попал на метаданные, они стали неконсистентны и том не монтируется - как-то хреново получается. Fsck как правило без особых проблем такое исправляет. А у zfs'ников в таких случаях или пляска с дискэдитором или лезут за бэкапами.
> По крайней мере zfs файловая система и концепция CoW - это система
> которая гарантирует 100% сохранность данных и 100% консистентность данных при любых
> записях и четния данныхКак ни странно, журналирующие файловые системы пытаются гарантирвоать то же самое, просто более топорным и тормозным методом, который по этой причине часто даунгрейдят до гарантий только насчет метаданных, но не данных. Что, разумеется, компромисс. CoW - это синоним гигантского журнала, размером на всю файловую систему. Поэтому и не надо 2 раза записывать данные при журналировании.
> (при ресетах при записи и прочее) но совершенно не гарантирует сохранность
> данных когда сама файловая система поврежденаа (будь то бед блоки и прочее).Как ни странно, классические журналирующие ФС занимаются тем же самым, с той разницей что часто для ускорения работы гарантии применяются только к метаданным но не данным, т.к. в отличие от CoW обычной фс надо записывать при журналинге данные 2 раза. CoW этого избегает и там полный журналинг данных происходит с скоростью близкой к нежурналируемой записи.
> Для этого и существуют raid1/raidz/raid2z/raid3z и бекапы.
Так и скажите: мы не можем восстановить серьезно разрушенную ФС. Вертитесь как уж на сковородке, лишь бы не признавать очевидный факт.
> Глупо как то звучит - сверхнадежная файловая система, но при ее повреждении
> "пытается отколупать останки тома из того что получилось". :)Еще глупее получается когда нет бэкапа, есть почти исправный диск, но из-за пары бэдов в неподходящем месте надо или забыть о всех данных, или колупать все эти навороты хекс-редактором.
> Какой смысл в fsck если он не гарантирует 100% востановление из бед-блоков
> для фс, которая позифионаруется как сверхнадежная?Сверхнадежно просрать все данные на томе при повреждении тома - вариант! Нет данных - нет проблем. Но мне этот вариант не нравится.
> Однако,
> меня устроит и 99.9% данных с диска особенно если бэкапа не было или он старый.Почти всегда при ликвидации fsck-ом повреждений файловой системы происходит частичная потеря информации.
Класно бы звучало:
Я:
- у меня сверхнадежная файловая система, проверка четности на лету, raidz3, +2 диска в hotspare
Fsck:
- е-е-е, тут это, малость данные подрежденны и я не знаю насколько это серьезно, примаунтить вроде можно, но что там за внутри твориться - четрт его знает
Я:
-ладно и так сойдет :)
Через два месяца оказывается что самый нужный файл таки битый.
Я:
- так, где там мой бекап старый, а я его уже затер новым бекапом, думая что там 99.9% нормальные, а оказалось только 99.8999% из них нормальные.
Вопрос: что вы будете делать с этой fs после того как востановили на 99.9% и знаете что там уже по ней беды пробежались. Продолжать пользоваться?>> Концепция fsck - это востановления из журналов и прочее при ресете OS и
>> всяких нештатных ситуациях,
>Например, fsck возможен на нежурналинуемом EXT2.Как бы фраза " и прочее" это и подразумевала. Сам долгое время пользовался UFS нежурналируемой. Когда дыски выросли до 2Tb как то жутко стало думать об fsck. Оно 100Гб проверяет - застрелится как долго.
>Журналируемой ФС не нужен fsck при просто ребуте.
Прям глаза открыли. Спасибо.
> таких случаях или пляска с дискэдитором или лезут за бэкапами.
Ну щас уже ситуация куда лучше. v28 уже портировали.
> Как ни странно, журналирующие файловые системы пытаются гарантирвоать то же самое, простоКлючевое слово "пытаются". Тоесть почти надежная файловая система. О чем мы вобще спорим, я уже начинаю путаться. О том что топлое - это не то же самое что твердое?
> до гарантий только насчет метаданных, но не данных. Что, разумеется, компромисс.
В понятие надежной файловой системы слово "компромис" не входит, хотя в zfs включили возможность отключать проверку данных. Это наверное для вас.
> Так и скажите: мы не можем восстановить серьезно разрушенную ФС. Вертитесь как
> уж на сковородке, лишь бы не признавать очевидный факт.Так я так и говорю - если zfs видит что не может 100% определить, что поврежденно и об этом отрапортовать, она просто не монтируется. Если может определить что бытие такие то файлы или метаданные - она с радостю монтируется и говорит вот тут вот это не доступно. Но хочу заметить - со 100%-ной вероятностю (баги в софте не берем в учет).
> Еще глупее получается когда нет бэкапа, есть почти исправный диск, но из-за
> пары бэдов в неподходящем месте надо или забыть о всех данных,Это вы свои фотографии с домашнего компа можете так доставать когда пару бедов на диске. Пойдите достаньте 500Гб-ую базу данных, и потом поди глянь как она будет после этого работать. Вас быстро вздрючат и за отсутствие бекапов и за ваш fsck.
> Сверхнадежно просрать все данные на томе при повреждении тома - вариант! Нет
> данных - нет проблем. Но мне этот вариант не нравится.Лучше ужасный конец чем ужас без конца и выпадение в кернел-паники и прочее по непонятным причинам. Про ваши фотки речи не идет.
> А потом бравые бсдшники собирают свои ZFSные пулы чуть ли не хексэдитором.
> Чья бы мычала, с своими практически отсутствующими тулзами для восстановления тяжело
> разрушенной ФС.Было: http://www.lissyara.su/articles/freebsd/file_system/zfs_reco.../
Стало: http://www.mail-archive.com/freebsd-stable@freebsd.org/...
---
- zpool import -F. Allows to rewind corrupted pool to earlier
transaction group
- possibility to import pool in read-only mode
---
> Было: http://www.lissyara.su/articles/freebsd/file_system/zfs_reco.../
> Стало: http://www.mail-archive.com/freebsd-stable@freebsd.org/...Это не значит что не придется плясать с бубном как в первом случае в других ситуациях ;). Представь себе, что бэд вылез в середине цепочки снапшотов и откат на столь давнюю позицию всего пула - не является приемлимым вариантом. Что дальше?
> да еще с отключеным проверкой данных (только метадынные проверяются) будет априори
> быстрее zfs. Ну что же, комуто важна скорость в ущерб функционала.http://66.135.57.166/lists/linux-ext4/msg24047.html
http://ru.wikipedia.org/wiki/Функционал
> http://66.135.57.166/lists/linux-ext4/msg24047.htmlИ что? то что влключить проверку данных можно на ext4 - это не секрет. Вопрос в том как шустро это будет работать после этого.
> http://ru.wikipedia.org/wiki/Функционал
А вы я смотрю умный. Сколько раз энциклопедию перечитали?
> И что? то что влключить проверку данных можно на ext4 - это
> не секрет. Вопрос в том как шустро это будет работать после
> этого.Медленнее, чем было — как и для всех остальных ФС.
> А вы я смотрю умный. Сколько раз энциклопедию перечитали?Первый раз на эту страницу зашел чтобы пруф дать ;)
Вы оказались неспособны осознать что CoW и журнал - это одно и то же, просто в разной реализации. Утрируя, CoW - это такая журналирующая ФС, где область данных ликвидирована, а вместо нее область журнала расширена на весь диск. Это единственное концептуальное отличие. Все что оно этим достигает - раз области данных нет, не надо переносить ("коммитить") журнальные записи в область основной ФС. Это просто логичная оптимизация журналирования.
А вы даже не способны прочитать то о чемь мы спорим. Если включить проверку данных в ext4 то получим такой же тормоз как и zfs. Причем тут ваш заумный коментарий?
Хорошо, но от LVM не откажусь. Кроме снапшотов там есть и более вкусные плюшки. А вот использовать преимущества LVM и Ext4 буду и далее, вместе они позволяют очень гибко управлять дисковым пространством.