The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

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

"Представлен набор патчей с поддержкой снапшотов для файловой..."  +/
Сообщение от opennews (??) on 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
Новость: https://www.opennet.ru/opennews/art.shtml?num=30826

Ответить | Правка | Cообщить модератору

Оглавление

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


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

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

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

20. "Представлен набор патчей с поддержкой снапшотов для файловой..."  +/
Сообщение от anonymous (??) on 09-Июн-11, 04:30 
>потом быстренько откатиться

next3 не имеет возможности отката, это главный её недостаток - тамошние снапшоты представлюятся в виде файлов-образов внутри текущего состояния фс, их можно монтировать через mount -o loop,ro -t ext2 . полагаю что в ext4-snapshots сделано также.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

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

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

89. "Представлен набор патчей с поддержкой снапшотов для файловой..."  +/
Сообщение от iZEN (ok) on 11-Дек-12, 23:07 
> конечно.
> ведь снимки в btrfs это обычный subvolume.
> с любого снимка (rw-снимка и снимка root ессесно имеется в виду) можно
> просто загрузиться и дальше работать. всё, вот и весь откат.
> тут до этого даже zfs далеко.

Чего "далеко"?

Концепция "снимок файловой системы или тома" никак не может быть "rw", так как это — ЗАМОРОЖЕННОЕ состояние файловой системы. Его можно только читать. Чтобы на его основе получить образ живой файловой системы, снимок надо клонировать. Тогда появляется возможность читать и писать в клоне. ZFS всем этим обладает. А Btrfs что предлагает, концепцию клонирования томов под соусом снимков?


Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

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

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

это возможность фс запоминать текущее состояние с возможностью в дальнейшем обращаться к нему. удобно для снятия бэкапов, кроме того сами по себе снапшоты можно использовать как бэкапы.

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

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

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

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

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

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

какой бекап, снапшот создай?!

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

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

А если механика снапшотов облажается - он свои данные не просрет при этом случайно? :)

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

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

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

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

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

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

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

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

погугли про bdev_freeze и хватит нести бред.

Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

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

Почему все ламерские заявления пытаются косить под истину в последней инстанции?

Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

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

Наверное потому, что авторы этих заявлений, в отличие от вас, понимают, что снапшот на уровне менеджера томов не может никаким образом учитывать состояние хранимой на нем ФС ?

Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

62. "Представлен набор патчей с поддержкой снапшотов для файловой..."  –1 +/
Сообщение от Аноним (??) on 09-Июн-11, 21:59 
> А LVM уже не православно?

да отстой этот LVM, что вы с ним лезите.

Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

46. "Представлен набор патчей с поддержкой снапшотов для файловой..."  –4 +/
Сообщение от Аноним (??) on 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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

48. "Представлен набор патчей с поддержкой снапшотов для файловой..."  +2 +/
Сообщение от anonymous (??) on 09-Июн-11, 11:25 
Что сказать то хотел?

Разработчиков спросили: "а на сколько оно стабильно".

Ответили, что огромный плюс их подхода (по сравнению с снапшотами btrfs )в том, что старый fsck, десятками лет провереный на реальном боевом рабочем железе отработает как и раньше, то есть по крайней мере восстанавливаемость в случае сбоев не хуже чем голая ext3/4 по сравнению с btrfs. Единственное, что новый код, провереный только 2 года, каcается самих снапшотов. То есть, если железо сбойнуло и файловая система рухнула, даже если есть невыявленные еще ошибки в свежедобавляемом коде, всегда можно тупо удалить снапшоты и пройтись старым добрым fsck.

Никто не писал что новый код нестабилен или ТРЕБУЕТ удаления снапшотов для восстановления.

Короче, не позорь честное имя Анонимов.

Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

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

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

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

а что с ними не так?

Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

59. "Представлен набор патчей с поддержкой снапшотов для файловой..."  +/
Сообщение от metallic email(ok) on 09-Июн-11, 13:12 
> а что с ними не так?

Max volume size 1 EiB (limited to 16TiB because of e2fsprogs limitation)

Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

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

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

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

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

69. "Представлен набор патчей с поддержкой снапшотов для файловой..."  +1 +/
Сообщение от yalur email(ok) on 10-Июн-11, 16:13 
>восстановление и предотвращение появления бед-блоков -- это задача аппаратная а не фс.

И вы тоже видимо не знакомы с концепцией zfs - недоверять никому кроме себя. В отличие от ext4/3/2 и все старых fs - доверять диску и контроллеру. Так что вы обсолютно не правы - для этого и делаются рейды1/raidz/raid2z/raid3z что бы востанавливать данные при появлении бед блоков - недоверять контроллеру и диску

Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

71. "Представлен набор патчей с поддержкой снапшотов для файловой..."  +/
Сообщение от yalur email(ok) on 10-Июн-11, 16:27 
> легче, чем получить бед-блок, постольку в условиях аварийных отключений именно возможность
> ЕЁ восстановления решает.

Концепция CoW - при самый немыслимых аварийных отключения - фс ВСЕГДА 100% консистентна (мы тут не говорим об бед-блокак и повреждениях фс).  В таком случае fsck ей не нужен. А про выковыревание битых данных с помощю fsck уже обсуждалось.

Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

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

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

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

80. "Представлен набор патчей с поддержкой снапшотов для файловой..."  +/
Сообщение от Аноним (??) on 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 email(ok) on 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.

> Сверхнадежно просрать все данные на томе при повреждении тома - вариант! Нет
> данных - нет проблем. Но мне этот вариант не нравится.

Лучше ужасный конец чем ужас без конца и выпадение в кернел-паники и прочее по непонятным причинам. Про ваши фотки речи не идет.

Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

72. "Представлен набор патчей с поддержкой снапшотов для файловой..."  +/
Сообщение от iZEN (ok) on 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. "Представлен набор патчей с поддержкой снапшотов для файловой..."  +/
Сообщение от Аноним (??) on 13-Июн-11, 00:19 
> Было: http://www.lissyara.su/articles/freebsd/file_system/zfs_reco.../
> Стало: http://www.mail-archive.com/freebsd-stable@freebsd.org/...

Это не значит что не придется плясать с бубном как в первом случае в других ситуациях ;). Представь себе, что бэд вылез в середине цепочки снапшотов и откат на столь давнюю позицию всего пула - не является приемлимым вариантом. Что дальше?

Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

70. "Представлен набор патчей с поддержкой снапшотов для файловой..."  +/
Сообщение от qux (ok) on 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 email(ok) on 10-Июн-11, 17:52 
> http://66.135.57.166/lists/linux-ext4/msg24047.html

И что? то что влключить проверку данных можно на ext4 - это не секрет. Вопрос в том как шустро это будет работать после этого.

> http://ru.wikipedia.org/wiki/Функционал

А вы я смотрю умный. Сколько раз энциклопедию перечитали?

Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

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

Медленнее, чем было — как и для всех остальных ФС.


> А вы я смотрю умный. Сколько раз энциклопедию перечитали?

Первый раз на эту страницу зашел чтобы пруф дать ;)

Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

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

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

Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

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

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

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




Спонсоры:
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2020 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру