| 1.1, Аноним (-), 23:19, 08/06/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +4 +/– |
Прикольно! Снапшоты удобны, когда имеется поддержка с пакетным менеджером, как в yum для btrfs - можно поставить что-то посмотреть, а потом быстренько откатиться.
| | |
| |
| |
| Часть нити удалена модератором |
| |
| 4.56, anonymous (??), 12:45, 09/06/2011 [^] [^^] [^^^] [ответить]
| +2 +/– |
они сильно сказываются на производительности, требуют выделения дополнительного пространства, причём если свободное место там исчерпается, будет не очень приятно. для кратковременного создания снапшота, чтобы снять бэкап, возможности lvm достаточны, для долгого хранения сразу нескольких снапшотов - нет.
| | |
|
|
| 2.20, anonymous (??), 04:30, 09/06/2011 [^] [^^] [^^^] [ответить]
| +/– | |
>потом быстренько откатиться
next3 не имеет возможности отката, это главный её недостаток - тамошние снапшоты представлюятся в виде файлов-образов внутри текущего состояния фс, их можно монтировать через mount -o loop,ro -t ext2 . полагаю что в ext4-snapshots сделано также.
| | |
| |
| |
| 4.88, ананим (?), 13:33, 11/12/2012 [^] [^^] [^^^] [ответить]
| +/– |
конечно.
ведь снимки в btrfs это обычный subvolume.
с любого снимка (rw-снимка и снимка root ессесно имеется в виду) можно просто загрузиться и дальше работать. всё, вот и весь откат.
тут до этого даже zfs далеко.
| | |
| |
| 5.89, iZEN (ok), 23:07, 11/12/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > конечно.
> ведь снимки в btrfs это обычный subvolume.
> с любого снимка (rw-снимка и снимка root ессесно имеется в виду) можно
> просто загрузиться и дальше работать. всё, вот и весь откат.
> тут до этого даже zfs далеко.
Чего "далеко"?
Концепция "снимок файловой системы или тома" никак не может быть "rw", так как это — ЗАМОРОЖЕННОЕ состояние файловой системы. Его можно только читать. Чтобы на его основе получить образ живой файловой системы, снимок надо клонировать. Тогда появляется возможность читать и писать в клоне. ZFS всем этим обладает. А Btrfs что предлагает, концепцию клонирования томов под соусом снимков?
| | |
|
|
|
|
| |
| 2.21, anonymous (??), 04:33, 09/06/2011 [^] [^^] [^^^] [ответить]
| +2 +/– | |
>В целях повышения образованности: что это такое и какие приносит блага?
это возможность фс запоминать текущее состояние с возможностью в дальнейшем обращаться к нему. удобно для снятия бэкапов, кроме того сами по себе снапшоты можно использовать как бэкапы.
| | |
| 2.58, Elhana (ok), 12:55, 09/06/2011 [^] [^^] [^^^] [ответить]
| +/– |
 Например в можно сделать снапшот, поставить апдейты, понять что ничего не работает и просто вернуться назад без проблем. Можно открыть снапшот за вчера и достать файл, который только что случайно грохнул и т.п. При этом по ставнению с полным бэкапом ФС хранит только изменения файлов, а не копию файла на каждый день.
| | |
|
| 1.17, Buy (??), 02:47, 09/06/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Скачал предкомпилированную версию. Забекаплюсь, буду тестить ;)
| | |
| |
| 2.25, Аноним (-), 04:53, 09/06/2011 [^] [^^] [^^^] [ответить]
| +/– | |
> какой бекап, снапшот создай?!
А если механика снапшотов облажается - он свои данные не просрет при этом случайно? :)
| | |
|
| |
| 2.54, Антоним (?), 12:28, 09/06/2011 [^] [^^] [^^^] [ответить]
| +/– |
LVM не умеет подгонять размер снапшота под фактические нужды, Уйдёт снапшот за резервирование и всё. Едва ли такую убогую функциональность можно назвать юзабильной. Это ещё не говоря о скорости снапшотов в lvm
| | |
| |
| 3.61, Антоним (?), 21:55, 09/06/2011 [^] [^^] [^^^] [ответить]
| +/– |
ах да, ещё в LVM нельзя сделать консистентный снапшот смонтированной в rw файловой системы
| | |
| |
| 4.64, anonymous (??), 03:58, 10/06/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
при создании снапшота lvm фс подготавливается к этому, если умеет (ext3, ext4, xfs умеют). впрочем, это нисколько не уменьшает других недостатков снапшотов lvm.
| | |
| |
| |
| 6.77, anonymous (??), 20:17, 10/06/2011 [^] [^^] [^^^] [ответить]
| +2 +/– | |
>ну да, поддержка называется mount -o remount,ro
погугли про bdev_freeze и хватит нести бред.
| | |
|
|
| 4.79, Аноним (-), 00:26, 13/06/2011 [^] [^^] [^^^] [ответить]
| –1 +/– |
> ах да, ещё в LVM нельзя сделать консистентный снапшот смонтированной в rw
> файловой системы
Почему все ламерские заявления пытаются косить под истину в последней инстанции?
| | |
| |
| 5.83, Аноним (-), 11:32, 13/06/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
>> ах да, ещё в LVM нельзя сделать консистентный снапшот смонтированной в rw
>> файловой системы
> Почему все ламерские заявления пытаются косить под истину в последней инстанции?
Наверное потому, что авторы этих заявлений, в отличие от вас, понимают, что снапшот на уровне менеджера томов не может никаким образом учитывать состояние хранимой на нем ФС ?
| | |
|
|
|
| 2.62, Аноним (-), 21:59, 09/06/2011 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> А LVM уже не православно?
да отстой этот LVM, что вы с ним лезите.
| | |
| |
| 3.90, swarus (ok), 23:36, 21/09/2023 [^] [^^] [^^^] [ответить]
| +/– |
 Зачем общий функционал выносить в отдельную программу, пускай каждый пишет свой велосипед заново.
Есть LVM, LUKS они хорошо работают, почему btrfs пилят свой велосипед? тем более не все виды рейда, в отличие от lvm, не поддерживают?
с ZFS ещё понятно оно в другой os родилось, но btrfs?
| | |
|
|
| 1.46, Аноним (-), 10:56, 09/06/2011 [ответить] [﹢﹢﹢] [ · · · ]
| –4 +/– | |
http://thread.gmane.org/gmane.comp.file-systems.ext4/25968/focus=26009
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
| | |
| |
| 2.48, anonymous (??), 11:25, 09/06/2011 [^] [^^] [^^^] [ответить]
| +2 +/– | |
Что сказать то хотел?
Разработчиков спросили: "а на сколько оно стабильно".
Ответили, что огромный плюс их подхода (по сравнению с снапшотами btrfs )в том, что старый fsck, десятками лет провереный на реальном боевом рабочем железе отработает как и раньше, то есть по крайней мере восстанавливаемость в случае сбоев не хуже чем голая ext3/4 по сравнению с btrfs. Единственное, что новый код, провереный только 2 года, каcается самих снапшотов. То есть, если железо сбойнуло и файловая система рухнула, даже если есть невыявленные еще ошибки в свежедобавляемом коде, всегда можно тупо удалить снапшоты и пройтись старым добрым fsck.
Никто не писал что новый код нестабилен или ТРЕБУЕТ удаления снапшотов для восстановления.
Короче, не позорь честное имя Анонимов.
| | |
|
| |
| |
| 3.59, metallic (ok), 13:12, 09/06/2011 [^] [^^] [^^^] [ответить]
| +/– |
 > а что с ними не так?
Max volume size 1 EiB (limited to 16TiB because of e2fsprogs limitation)
| | |
|
|
| 1.63, yalur (ok), 01:22, 10/06/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 И кто то еще бочку катит на zfs с ее медленостю. Ясное дело что такая убогая фс как ext4 с таким убогим функционалом да еще с отключеным проверкой данных (только метадынные проверяются) будет априори быстрее zfs. Ну что же, комуто важна скорость в ущерб функционала. Даже не знал что ext4 снапшоты не поддерживает. Про клоны я вообще молчу o_O
| | |
| |
| 2.66, Аноним (-), 13:57, 10/06/2011 [^] [^^] [^^^] [ответить]
| +/– |
А потом бравые бсдшники собирают свои ZFSные пулы чуть ли не хексэдитором. Чья бы мычала, с своими практически отсутствующими тулзами для восстановления тяжело разрушенной ФС. У EXTов их fsck по крайней мере до последнего пытается отколупать останки тома из того что получилось. А zfs при этом тихо умрет и восстановлению будет подлежать только хексэдитором разве что.
| | |
| |
| 3.67, yalur (ok), 14:44, 10/06/2011 [^] [^^] [^^^] [ответить] | +/– | Вы путаете товарищ что то, если востановление этим вашим хваленых fsck не гарант... большой текст свёрнут, показать | | |
| |
| 4.68, ano (??), 15:21, 10/06/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
восстановление и предотвращение появления бед-блоков -- это задача аппаратная а не фс. да и никакие рэйды не гарантируют 100% надёжности -- всегда есть вероятность что навернётся СРАЗУ ВСЁ!!1, например. а поскольку угробить фс значительно легче, чем получить бед-блок, постольку в условиях аварийных отключений именно возможность ЕЁ восстановления решает.
| | |
| |
| 5.69, yalur (ok), 16:13, 10/06/2011 [^] [^^] [^^^] [ответить]
| +1 +/– | |
>восстановление и предотвращение появления бед-блоков -- это задача аппаратная а не фс.
И вы тоже видимо не знакомы с концепцией zfs - недоверять никому кроме себя. В отличие от ext4/3/2 и все старых fs - доверять диску и контроллеру. Так что вы обсолютно не правы - для этого и делаются рейды1/raidz/raid2z/raid3z что бы востанавливать данные при появлении бед блоков - недоверять контроллеру и диску
| | |
| 5.71, yalur (ok), 16:27, 10/06/2011 [^] [^^] [^^^] [ответить]
| +/– |
> легче, чем получить бед-блок, постольку в условиях аварийных отключений именно возможность
> ЕЁ восстановления решает.
Концепция CoW - при самый немыслимых аварийных отключения - фс ВСЕГДА 100% консистентна (мы тут не говорим об бед-блокак и повреждениях фс). В таком случае fsck ей не нужен. А про выковыревание битых данных с помощю fsck уже обсуждалось.
| | |
| |
| 6.73, ano (??), 17:08, 10/06/2011 [^] [^^] [^^^] [ответить]
| +/– |
концепция -- хорошо, а на практике -- за последние два года в нашем грёбаном тьмутаракановске рабочая станция под xp + ntfs гробила фс 7 раз, почтовик-файлопомойка-роутер c free-bsd + zfs -- 1 раз, а радио-сервер/собиратор/компиляйтор/обогреватель с gentoo + ext3 -- 0 раз, бэд-блоков ни на одной машине не наблюдалось. по мне, это говорит гораздо больше, чем тонны концепций и прочих контрацепций.
| | |
| |
| 7.74, yalur (ok), 17:22, 10/06/2011 [^] [^^] [^^^] [ответить]
| +/– |
Все это говорит лиш о том:
1) недостаточно статистики
2) любая концепция хоть как она не идеальна, реализовуется иногда с багами в софте, и далеко не идеальными руками.
:)
| | |
| |
| 8.82, Аноним (-), 01:08, 13/06/2011 [^] [^^] [^^^] [ответить] | +1 +/– | Все это говорит о том что запасной парашют в виде fsck - это не опциональный акс... текст свёрнут, показать | | |
|
|
|
|
| 4.80, Аноним (-), 00:51, 13/06/2011 [^] [^^] [^^^] [ответить] | +/– | Разумеется, 100 данных если часть данных не читаема восстановить не удастся Од... большой текст свёрнут, показать | | |
| |
| 5.86, yalur (ok), 20:49, 15/06/2011 [^] [^^] [^^^] [ответить] | +/– | Почти всегда при ликвидации fsck-ом повреждений файловой системы происходит част... большой текст свёрнут, показать | | |
|
|
|
| |
| |
| 4.76, qux (ok), 19:15, 10/06/2011 [^] [^^] [^^^] [ответить]
| +/– |
 > И что? то что влключить проверку данных можно на ext4 - это
> не секрет. Вопрос в том как шустро это будет работать после
> этого.
Медленнее, чем было — как и для всех остальных ФС.
> А вы я смотрю умный. Сколько раз энциклопедию перечитали?
Первый раз на эту страницу зашел чтобы пруф дать ;)
| | |
| 4.81, Аноним (-), 01:01, 13/06/2011 [^] [^^] [^^^] [ответить]
| +/– |
Вы оказались неспособны осознать что CoW и журнал - это одно и то же, просто в разной реализации. Утрируя, CoW - это такая журналирующая ФС, где область данных ликвидирована, а вместо нее область журнала расширена на весь диск. Это единственное концептуальное отличие. Все что оно этим достигает - раз области данных нет, не надо переносить ("коммитить") журнальные записи в область основной ФС. Это просто логичная оптимизация журналирования.
| | |
| |
| 5.85, yalur (ok), 19:47, 15/06/2011 [^] [^^] [^^^] [ответить]
| +/– | |
А вы даже не способны прочитать то о чемь мы спорим. Если включить проверку данных в ext4 то получим такой же тормоз как и zfs. Причем тут ваш заумный коментарий?
| | |
|
|
|
|
| 1.84, lucentcode (ok), 00:43, 15/06/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Хорошо, но от LVM не откажусь. Кроме снапшотов там есть и более вкусные плюшки. А вот использовать преимущества LVM и Ext4 буду и далее, вместе они позволяют очень гибко управлять дисковым пространством.
| | |
|
