Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Представлен набор патчей с поддержкой снапшотов для файловой..."	+/–
Сообщение от opennews (??), 08-Июн-11, 23:19
Разработчики проекта 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.me/opennews/art.shtml?num=30826
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

1. "Представлен набор патчей с поддержкой снапшотов для файловой..."	+4 +/–
Сообщение от Аноним (-), 08-Июн-11, 23:19
Прикольно! Снапшоты удобны, когда имеется поддержка с пакетным менеджером, как в yum для btrfs - можно поставить что-то посмотреть, а потом быстренько откатиться.
Ответить | Правка | Наверх | Cообщить модератору

Часть нити удалена модератором

	42. "Представлен набор патчей с поддержкой снапшотов для файловой..."	–1 +/–
	Сообщение от Бублик (?), 09-Июн-11, 10:33
	А чем снимки в LVM не подходят?
	Ответить | Правка | Наверх | Cообщить модератору

	56. "Представлен набор патчей с поддержкой снапшотов для файловой..."	+2 +/–
	Сообщение от anonymous (??), 09-Июн-11, 12:45
	они сильно сказываются на производительности, требуют выделения дополнительного пространства, причём если свободное место там исчерпается, будет не очень приятно. для кратковременного создания снапшота, чтобы снять бэкап, возможности lvm достаточны, для долгого хранения сразу нескольких снапшотов - нет.
	Ответить | Правка | Наверх | Cообщить модератору

	20. "Представлен набор патчей с поддержкой снапшотов для файловой..."	+/–
	Сообщение от anonymous (??), 09-Июн-11, 04:30
	>потом быстренько откатиться next3 не имеет возможности отката, это главный её недостаток - тамошние снапшоты представлюятся в виде файлов-образов внутри текущего состояния фс, их можно монтировать через mount -o loop,ro -t ext2 . полагаю что в ext4-snapshots сделано также.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	52. "Представлен набор патчей с поддержкой снапшотов для файловой..."	+/–
	Сообщение от Manbearpig (?), 09-Июн-11, 12:14
	тогда они никак не могут стать заменой снимков из бтрфс
	Ответить | Правка | Наверх | Cообщить модератору

	88. "Представлен набор патчей с поддержкой снапшотов для файловой..."	+/–
	Сообщение от ананим (?), 11-Дек-12, 13:33
	конечно. ведь снимки в btrfs это обычный subvolume. с любого снимка (rw-снимка и снимка root ессесно имеется в виду) можно просто загрузиться и дальше работать. всё, вот и весь откат. тут до этого даже zfs далеко.
	Ответить | Правка | Наверх | Cообщить модератору

	89. "Представлен набор патчей с поддержкой снапшотов для файловой..."	+1 +/–
	Сообщение от iZEN (ok), 11-Дек-12, 23:07
	> конечно. > ведь снимки в btrfs это обычный subvolume. > с любого снимка (rw-снимка и снимка root ессесно имеется в виду) можно > просто загрузиться и дальше работать. всё, вот и весь откат. > тут до этого даже zfs далеко. Чего "далеко"? Концепция "снимок файловой системы или тома" никак не может быть "rw", так как это — ЗАМОРОЖЕННОЕ состояние файловой системы. Его можно только читать. Чтобы на его основе получить образ живой файловой системы, снимок надо клонировать. Тогда появляется возможность читать и писать в клоне. ZFS всем этим обладает. А Btrfs что предлагает, концепцию клонирования томов под соусом снимков?
	Ответить | Правка | Наверх | Cообщить модератору

5. "Представлен набор патчей с поддержкой снапшотов для файловой..."	+/–
Сообщение от alltiptop (ok), 08-Июн-11, 23:52
В целях повышения образованности: что это такое и какие приносит блага?
Ответить | Правка | Наверх | Cообщить модератору

	21. "Представлен набор патчей с поддержкой снапшотов для файловой..."	+2 +/–
	Сообщение от anonymous (??), 09-Июн-11, 04:33
	>В целях повышения образованности: что это такое и какие приносит блага? это возможность фс запоминать текущее состояние с возможностью в дальнейшем обращаться к нему. удобно для снятия бэкапов, кроме того сами по себе снапшоты можно использовать как бэкапы.
	Ответить | Правка | Наверх | Cообщить модератору

	58. "Представлен набор патчей с поддержкой снапшотов для файловой..."	+/–
	Сообщение от Elhana (ok), 09-Июн-11, 12:55
	Например в можно сделать снапшот, поставить апдейты, понять что ничего не работает и просто вернуться назад без проблем. Можно открыть снапшот за вчера и достать файл, который только что случайно грохнул и т.п. При этом по ставнению с полным бэкапом ФС хранит только изменения файлов, а не копию файла на каждый день.
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

9. "Представлен набор патчей с поддержкой снапшотов для файловой..."	–1 +/–
Сообщение от jsp (ok), 09-Июн-11, 00:49
ext5???
Ответить | Правка | Наверх | Cообщить модератору

	60. "Представлен набор патчей с поддержкой снапшотов для файловой..."	+/–
	Сообщение от Аноним (-), 09-Июн-11, 17:38
	Ещё не закончил конвертировать диск в ext4...
	Ответить | Правка | Наверх | Cообщить модератору

17. "Представлен набор патчей с поддержкой снапшотов для файловой..."	+/–
Сообщение от Buy (??), 09-Июн-11, 02:47
Скачал предкомпилированную версию. Забекаплюсь, буду тестить ;)
Ответить | Правка | Наверх | Cообщить модератору

18. "Представлен набор патчей с поддержкой снапшотов для файловой..."	+/–
Сообщение от Andrey (??), 09-Июн-11, 03:22
> Забекаплюсь, буду тестить ;) какой бекап, снапшот создай?!
Ответить | Правка | Наверх | Cообщить модератору

	25. "Представлен набор патчей с поддержкой снапшотов для файловой..."	+/–
	Сообщение от Аноним (-), 09-Июн-11, 04:53
	> какой бекап, снапшот создай?! А если механика снапшотов облажается - он свои данные не просрет при этом случайно? :)
	Ответить | Правка | Наверх | Cообщить модератору

43. "Представлен набор патчей с поддержкой снапшотов для файловой..."	+/–
Сообщение от Аноним (-), 09-Июн-11, 10:33
А LVM уже не православно?
Ответить | Правка | Наверх | Cообщить модератору

	45. "Представлен набор патчей с поддержкой снапшотов для файловой..."	+/–
	Сообщение от const86 (ok), 09-Июн-11, 10:42
	Написано же, в чём преимущества снапшотов ext4 перед lvm'ными.
	Ответить | Правка | Наверх | Cообщить модератору

	54. "Представлен набор патчей с поддержкой снапшотов для файловой..."	+/–
	Сообщение от Антоним (?), 09-Июн-11, 12:28
	LVM не умеет подгонять размер снапшота под фактические нужды, Уйдёт снапшот за резервирование и всё. Едва ли такую убогую функциональность можно назвать юзабильной. Это ещё не говоря о скорости снапшотов в lvm
	Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

	61. "Представлен набор патчей с поддержкой снапшотов для файловой..."	+/–
	Сообщение от Антоним (?), 09-Июн-11, 21:55
	ах да, ещё в LVM нельзя сделать консистентный снапшот смонтированной в rw файловой системы
	Ответить | Правка | Наверх | Cообщить модератору

	64. "Представлен набор патчей с поддержкой снапшотов для файловой..."	+1 +/–
	Сообщение от anonymous (??), 10-Июн-11, 03:58
	при создании снапшота lvm фс подготавливается к этому, если умеет (ext3, ext4, xfs умеют). впрочем, это нисколько не уменьшает других недостатков снапшотов lvm.
	Ответить | Правка | Наверх | Cообщить модератору

	65. "Представлен набор патчей с поддержкой снапшотов для файловой..."	–2 +/–
	Сообщение от Антоним (?), 10-Июн-11, 13:48
	ну да, поддержка называется mount -o remount,ro. Очень круто.
	Ответить | Правка | Наверх | Cообщить модератору

	77. "Представлен набор патчей с поддержкой снапшотов для файловой..."	+2 +/–
	Сообщение от anonymous (??), 10-Июн-11, 20:17
	>ну да, поддержка называется mount -o remount,ro погугли про bdev_freeze и хватит нести бред.
	Ответить | Правка | Наверх | Cообщить модератору

	79. "Представлен набор патчей с поддержкой снапшотов для файловой..."	–1 +/–
	Сообщение от Аноним (-), 13-Июн-11, 00:26
	> ах да, ещё в LVM нельзя сделать консистентный снапшот смонтированной в rw > файловой системы Почему все ламерские заявления пытаются косить под истину в последней инстанции?
	Ответить | Правка | К родителю #61 | Наверх | Cообщить модератору

	83. "Представлен набор патчей с поддержкой снапшотов для файловой..."	+1 +/–
	Сообщение от Аноним (-), 13-Июн-11, 11:32
	>> ах да, ещё в LVM нельзя сделать консистентный снапшот смонтированной в rw >> файловой системы > Почему все ламерские заявления пытаются косить под истину в последней инстанции? Наверное потому, что авторы этих заявлений, в отличие от вас, понимают, что снапшот на уровне менеджера томов не может никаким образом учитывать состояние хранимой на нем ФС ?
	Ответить | Правка | Наверх | Cообщить модератору

	62. "Представлен набор патчей с поддержкой снапшотов для файловой..."	–1 +/–
	Сообщение от Аноним (-), 09-Июн-11, 21:59
	> А LVM уже не православно? да отстой этот LVM, что вы с ним лезите.
	Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

	90. "Представлен набор патчей с поддержкой снапшотов для файловой..."	+/–
	Сообщение от swarus (ok), 21-Сен-23, 23:36
	Зачем общий функционал выносить в отдельную программу, пускай каждый пишет свой велосипед заново. Есть LVM, LUKS они хорошо работают, почему btrfs пилят свой велосипед? тем более не все виды рейда, в отличие от lvm, не поддерживают? с ZFS ещё понятно оно в другой os родилось, но btrfs?
	Ответить | Правка | Наверх | Cообщить модератору

46. "Представлен набор патчей с поддержкой снапшотов для файловой..."	–4 +/–
Сообщение от Аноним (-), 09-Июн-11, 10:56
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
Ответить | Правка | Наверх | Cообщить модератору

	48. "Представлен набор патчей с поддержкой снапшотов для файловой..."	+2 +/–
	Сообщение от anonymous (??), 09-Июн-11, 11:25
	Что сказать то хотел? Разработчиков спросили: "а на сколько оно стабильно". Ответили, что огромный плюс их подхода (по сравнению с снапшотами btrfs )в том, что старый fsck, десятками лет провереный на реальном боевом рабочем железе отработает как и раньше, то есть по крайней мере восстанавливаемость в случае сбоев не хуже чем голая ext3/4 по сравнению с btrfs. Единственное, что новый код, провереный только 2 года, каcается самих снапшотов. То есть, если железо сбойнуло и файловая система рухнула, даже если есть невыявленные еще ошибки в свежедобавляемом коде, всегда можно тупо удалить снапшоты и пройтись старым добрым fsck. Никто не писал что новый код нестабилен или ТРЕБУЕТ удаления снапшотов для восстановления. Короче, не позорь честное имя Анонимов.
	Ответить | Правка | Наверх | Cообщить модератору

	49. "Представлен набор патчей с поддержкой снапшотов для файловой..."	+1 +/–
	Сообщение от Онаним (?), 09-Июн-11, 11:32
	Что не так? Снапшоты бакапы не отменяют. Или Вы не в курсе?
	Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

50. "Представлен набор патчей с поддержкой снапшотов для файловой..."	+/–
Сообщение от metallic (ok), 09-Июн-11, 11:58
Они бы лучше утилиты допилили, а то срам.
Ответить | Правка | Наверх | Cообщить модератору

	57. "Представлен набор патчей с поддержкой снапшотов для файловой..."	+/–
	Сообщение от anonymous (??), 09-Июн-11, 12:47
	> Они бы лучше утилиты допилили, а то срам. а что с ними не так?
	Ответить | Правка | Наверх | Cообщить модератору

	59. "Представлен набор патчей с поддержкой снапшотов для файловой..."	+/–
	Сообщение от metallic (ok), 09-Июн-11, 13:12
	> а что с ними не так? Max volume size 1 EiB (limited to 16TiB because of e2fsprogs limitation)
	Ответить | Правка | Наверх | Cообщить модератору

63. "Представлен набор патчей с поддержкой снапшотов для файловой..."	+/–
Сообщение от yalur (ok), 10-Июн-11, 01:22
И кто то еще бочку катит на zfs с ее медленостю. Ясное дело что такая убогая фс как ext4 с таким убогим функционалом да еще с отключеным проверкой данных (только метадынные проверяются) будет априори быстрее zfs. Ну что же, комуто важна скорость в ущерб функционала. Даже не знал что ext4 снапшоты не поддерживает. Про клоны я вообще молчу o_O
Ответить | Правка | Наверх | Cообщить модератору

	66. "Представлен набор патчей с поддержкой снапшотов для файловой..."	+/–
	Сообщение от Аноним (-), 10-Июн-11, 13:57
	А потом бравые бсдшники собирают свои ZFSные пулы чуть ли не хексэдитором. Чья бы мычала, с своими практически отсутствующими тулзами для восстановления тяжело разрушенной ФС. У EXTов их fsck по крайней мере до последнего пытается отколупать останки тома из того что получилось. А zfs при этом тихо умрет и восстановлению будет подлежать только хексэдитором разве что.
	Ответить | Правка | Наверх | Cообщить модератору

	67. "Представлен набор патчей с поддержкой снапшотов для файловой..."	+/–
	Сообщение от yalur (ok), 10-Июн-11, 14:44
	Вы путаете товарищ что то, если востановление этим вашим хваленых fsck не гарантирует 100% востановления файловой системы, а бед-блок когда там потеряны данные - это 100%-ов что ни о каких 100%-ах востановленых данных и речи быть не может. Концепция fsck - это востановления из журналов и прочее при ресете OS и всяких нештатных ситуациях, тоесть востановление структуры файловой системы, а не востановление бед-блоков. Бед-блок востановить невозможно, если нету бекапов либо raid1,raidz и так далее. По крайней мере zfs файловая система и концепция CoW - это система которая гарантирует 100% сохранность данных и 100% консистентность данных при любых записях и четния данных (при ресетах при записи и прочее) но совершенно не гарантирует сохранность данных когда сама файловая система поврежденаа (будь то бед блоки и прочее). Для этого и существуют raid1/raidz/raid2z/raid3z и бекапы. Глупо как то звучит - сверхнадежная файловая система, но при ее повреждении "пытается отколупать останки тома из того что получилось". :) Какой смысл в fsck если он не гарантирует 100% востановление из бед-блоков для фс, которая позифионаруется как сверхнадежная?
	Ответить | Правка | Наверх | Cообщить модератору

	68. "Представлен набор патчей с поддержкой снапшотов для файловой..."	+1 +/–
	Сообщение от ano (??), 10-Июн-11, 15:21
	восстановление и предотвращение появления бед-блоков -- это задача аппаратная а не фс. да и никакие рэйды не гарантируют 100% надёжности -- всегда есть вероятность что навернётся СРАЗУ ВСЁ!!1, например. а поскольку угробить фс значительно легче, чем получить бед-блок, постольку в условиях аварийных отключений именно возможность ЕЁ восстановления решает.
	Ответить | Правка | Наверх | Cообщить модератору

	69. "Представлен набор патчей с поддержкой снапшотов для файловой..."	+1 +/–
	Сообщение от yalur (ok), 10-Июн-11, 16:13
	>восстановление и предотвращение появления бед-блоков -- это задача аппаратная а не фс. И вы тоже видимо не знакомы с концепцией zfs - недоверять никому кроме себя. В отличие от ext4/3/2 и все старых fs - доверять диску и контроллеру. Так что вы обсолютно не правы - для этого и делаются рейды1/raidz/raid2z/raid3z что бы востанавливать данные при появлении бед блоков - недоверять контроллеру и диску
	Ответить | Правка | Наверх | Cообщить модератору

	71. "Представлен набор патчей с поддержкой снапшотов для файловой..."	+/–
	Сообщение от yalur (ok), 10-Июн-11, 16:27
	> легче, чем получить бед-блок, постольку в условиях аварийных отключений именно возможность > ЕЁ восстановления решает. Концепция CoW - при самый немыслимых аварийных отключения - фс ВСЕГДА 100% консистентна (мы тут не говорим об бед-блокак и повреждениях фс).  В таком случае fsck ей не нужен. А про выковыревание битых данных с помощю fsck уже обсуждалось.
	Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

	73. "Представлен набор патчей с поддержкой снапшотов для файловой..."	+/–
	Сообщение от ano (??), 10-Июн-11, 17:08
	концепция -- хорошо, а на практике -- за последние два года в нашем грёбаном тьмутаракановске рабочая станция под xp + ntfs гробила фс 7 раз, почтовик-файлопомойка-роутер c free-bsd + zfs -- 1 раз, а радио-сервер/собиратор/компиляйтор/обогреватель с gentoo + ext3 -- 0 раз, бэд-блоков ни на одной машине не наблюдалось. по мне, это говорит гораздо больше, чем тонны концепций и прочих контрацепций.
	Ответить | Правка | Наверх | Cообщить модератору

	74. "Представлен набор патчей с поддержкой снапшотов для файловой..."	+/–
	Сообщение от yalur (ok), 10-Июн-11, 17:22
	Все это говорит лиш о том: 1) недостаточно статистики 2) любая концепция хоть как она не идеальна, реализовуется иногда с багами в софте, и далеко не идеальными руками. :)
	Ответить | Правка | Наверх | Cообщить модератору

	82. "Представлен набор патчей с поддержкой снапшотов для файловой..."	+1 +/–
	Сообщение от Аноним (-), 13-Июн-11, 01:08
	Все это говорит о том что запасной парашют в виде fsck - это не опциональный аксессуар, а суровая необходимость в реальных ситуациях.
	Ответить | Правка | Наверх | Cообщить модератору

	80. "Представлен набор патчей с поддержкой снапшотов для файловой..."	+/–
	Сообщение от Аноним (-), 13-Июн-11, 00:51
	> Вы путаете товарищ что то, если востановление этим вашим хваленых 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% востановление из бед-блоков > для фс, которая позифионаруется как сверхнадежная? Сверхнадежно просрать все данные на томе при повреждении тома - вариант! Нет данных - нет проблем. Но мне этот вариант не нравится.
	Ответить | Правка | К родителю #67 | Наверх | Cообщить модератору

	86. "Представлен набор патчей с поддержкой снапшотов для файловой..."	+/–
	Сообщение от yalur (ok), 15-Июн-11, 20:49
	> Однако, > меня устроит и 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. > Сверхнадежно просрать все данные на томе при повреждении тома - вариант! Нет > данных - нет проблем. Но мне этот вариант не нравится. Лучше ужасный конец чем ужас без конца и выпадение в кернел-паники и прочее по непонятным причинам. Про ваши фотки речи не идет.
	Ответить | Правка | Наверх | Cообщить модератору

	72. "Представлен набор патчей с поддержкой снапшотов для файловой..."	+/–
	Сообщение от iZEN (ok), 10-Июн-11, 16:32
	> А потом бравые бсдшники собирают свои 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 ---
	Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

	78. "Представлен набор патчей с поддержкой снапшотов для файловой..."	+/–
	Сообщение от Аноним (-), 13-Июн-11, 00:19
	> Было: http://www.lissyara.su/articles/freebsd/file_system/zfs_reco.../ > Стало: http://www.mail-archive.com/freebsd-stable@freebsd.org/... Это не значит что не придется плясать с бубном как в первом случае в других ситуациях ;). Представь себе, что бэд вылез в середине цепочки снапшотов и откат на столь давнюю позицию всего пула - не является приемлимым вариантом. Что дальше?
	Ответить | Правка | Наверх | Cообщить модератору

	70. "Представлен набор патчей с поддержкой снапшотов для файловой..."	+/–
	Сообщение от qux (ok), 10-Июн-11, 16:18
	> да еще с отключеным проверкой данных (только метадынные проверяются) будет априори > быстрее zfs. Ну что же, комуто важна скорость в ущерб функционала. http://66.135.57.166/lists/linux-ext4/msg24047.html http://ru.wikipedia.org/wiki/Функционал
	Ответить | Правка | К родителю #63 | Наверх | Cообщить модератору

	75. "Представлен набор патчей с поддержкой снапшотов для файловой..."	–1 +/–
	Сообщение от yalur (ok), 10-Июн-11, 17:52
	> http://66.135.57.166/lists/linux-ext4/msg24047.html И что? то что влключить проверку данных можно на ext4 - это не секрет. Вопрос в том как шустро это будет работать после этого. > http://ru.wikipedia.org/wiki/Функционал А вы я смотрю умный. Сколько раз энциклопедию перечитали?
	Ответить | Правка | Наверх | Cообщить модератору

	76. "Представлен набор патчей с поддержкой снапшотов для файловой..."	+/–
	Сообщение от qux (ok), 10-Июн-11, 19:15
	> И что? то что влключить проверку данных можно на ext4 - это > не секрет. Вопрос в том как шустро это будет работать после > этого. Медленнее, чем было — как и для всех остальных ФС. > А вы я смотрю умный. Сколько раз энциклопедию перечитали? Первый раз на эту страницу зашел чтобы пруф дать ;)
	Ответить | Правка | Наверх | Cообщить модератору

	81. "Представлен набор патчей с поддержкой снапшотов для файловой..."	+/–
	Сообщение от Аноним (-), 13-Июн-11, 01:01
	Вы оказались неспособны осознать что CoW и журнал - это одно и то же, просто в разной реализации. Утрируя, CoW - это такая журналирующая ФС, где область данных ликвидирована, а вместо нее область журнала расширена на весь диск. Это единственное концептуальное отличие. Все что оно этим достигает - раз области данных нет, не надо переносить ("коммитить") журнальные записи в область основной ФС. Это просто логичная оптимизация журналирования.
	Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

	85. "Представлен набор патчей с поддержкой снапшотов для файловой..."	+/–
	Сообщение от yalur (ok), 15-Июн-11, 19:47
	А вы даже не способны прочитать то о чемь мы спорим. Если включить проверку данных в ext4 то получим такой же тормоз как и zfs. Причем тут ваш заумный коментарий?
	Ответить | Правка | Наверх | Cообщить модератору

84. "Представлен набор патчей с поддержкой снапшотов для файловой..."	+/–
Сообщение от lucentcode (ok), 15-Июн-11, 00:43
Хорошо, но от LVM не откажусь. Кроме снапшотов там есть и более вкусные плюшки. А вот использовать преимущества LVM и Ext4 буду и далее, вместе они позволяют очень гибко управлять дисковым пространством.
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема