The OpenNET Project / Index page

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

Представлен набор патчей с поддержкой снапшотов для файловой системы Ext4

08.06.2011 22:14

Разработчики проекта NEXT3, в рамках которого уже несколько лет развивается неофициальная реализация поддержки мгновенных снимков состояния файловой системы Ext3 (снапшотов), представили первый выпуск набора патчей ext4-snapshots, обеспечивающих работу снапшотов в файловой системе Ext4.

Вопрос об интеграции представленного набора патчей в Linux-ядро пока не решен. Набор состоит из 36 патчей и интегрируется с Ext4 через систему стандартных хуков. Предусмотрена возможность монтирования разделов с отключением поддержки снапшотов, в этом случае код никак себя не проявляет и ФС Ext4 функционирует как раньше. В качестве причины развития проекта указано желание интегрировать возможность работы со снапшотами в уже зарекомендовавшую себя и повсеместно используемую ФС Ext4, вместо использования экспериментальной ФС Btrfs или системы dm_multisnap.

Разработка проекта ведется компанией CTERA Networks, которая использует код проекта NEXT3 в своих NAS-хранилищах и гибридных системах хранения данных. Несмотря на то, что патчи уже достаточно хорошо протестированы и отлажены в недрах компании CTERA, для интеграции их в ядро требуется более широкомасштабное тестирование и оценка их влияния на производительность. По заявлению разработчиков проекта патчи готовы к интеграции в состав Linux-ядра. Так как окно по принятию патчей для ядра 3.0 уже закрыто, а следующее будет только в августе, у энтузиастов есть несколько месяцев на проведение дополнительного тестирования.

В отличии от снапшотов на базе LVM, система снапшотов на уровне файловой системы обладает следующими преимуществами:

  • Снапшоты не требуют предварительного резервирования места, что позволяет гибко управлять доступным свободным пространством. Снапшоты Next3 являются компактными и требуют дополнительного места только для хранения изменений;
  • Близкая к линейной масштабируемость - даже при огромном количестве снапшотов скорость остается на уровне, близком к Ext4;
  • Поддержка инкрементальных снапшотов, доступных только на чтение (создаем снапшот: "snapshot.ext4dev take Monday", монтируем его: "snapshot.ext4dev mount Monday", удаляем: "snapshot.ext4dev delete Monday");
  • Снапшоты создаются и удаляются практически мгновенно. Сразу же после удаления снапшота занятое им пространство автоматически освобождается;
  • Полная прямая и обратная совместимость с Ext4. Миграция с Ext4 на вариант с поддержкой снапшотов и обратно выполняется буквально в три команды ("umount /dev/xxx; snapshot.ext4dev on /dev/xxx; mount -t ext4dev /dev/xxx").

Инструкцию по установке можно найти здесь (вместо модуля next3 следует указать ext4dev, а вместо скрипта next3 - snapshot.ext4dev). Тестовые патчи подготовлены для Linux-ядра 2.6.38 и протестированы в дистрибутивах Ubuntu 11.04 и Fedora 15. Загрузить предкомпилированную версию для систем x86_64 можно здесь.

  1. Главная ссылка к новости (http://permalink.gmane.org/gma...)
  2. Ext4 snapshots TODO
  3. OpenNews: Доклад Google о файловых системах Linux
  4. OpenNews: Открыт код Next3 - файловой системы для Linux с поддержкой снапшотов
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/30826-Ext4
Ключевые слова: Ext4, snapshot, patch, kernel, linux
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (51) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 23:19, 08/06/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Прикольно! Снапшоты удобны, когда имеется поддержка с пакетным менеджером, как в yum для btrfs - можно поставить что-то посмотреть, а потом быстренько откатиться.
     
     
     
    Часть нити удалена модератором

  • 3.42, Бублик (?), 10:33, 09/06/2011 [ответить]  
  • –1 +/
    А чем снимки в LVM не подходят?
     
     
  • 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 сделано также.

     
     
  • 3.52, Manbearpig (?), 12:14, 09/06/2011 [^] [^^] [^^^] [ответить]  
  • +/
    тогда они никак не могут стать заменой снимков из бтрфс
     
     
  • 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 что предлагает, концепцию клонирования томов под соусом снимков?


     

  • 1.5, alltiptop (ok), 23:52, 08/06/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    В целях повышения образованности: что это такое и какие приносит блага?
     
     
  • 2.21, anonymous (??), 04:33, 09/06/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >В целях повышения образованности: что это такое и какие приносит блага?

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

     
  • 2.58, Elhana (ok), 12:55, 09/06/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Например в можно сделать снапшот, поставить апдейты, понять что ничего не работает и просто вернуться назад без проблем. Можно открыть снапшот за вчера и достать файл, который только что случайно грохнул и т.п. При этом по ставнению с полным бэкапом ФС хранит только изменения файлов, а не копию файла на каждый день.
     

  • 1.9, jsp (ok), 00:49, 09/06/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    ext5???
     
     
  • 2.60, Аноним (-), 17:38, 09/06/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Ещё не закончил конвертировать диск в ext4...
     

  • 1.17, Buy (??), 02:47, 09/06/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Скачал предкомпилированную версию. Забекаплюсь, буду тестить ;)
     
  • 1.18, Andrey (??), 03:22, 09/06/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Забекаплюсь, буду тестить ;)

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

     
     
  • 2.25, Аноним (-), 04:53, 09/06/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > какой бекап, снапшот создай?!

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

     

  • 1.43, Аноним (-), 10:33, 09/06/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А LVM уже не православно?
     
     
  • 2.45, const86 (ok), 10:42, 09/06/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Написано же, в чём преимущества снапшотов ext4 перед lvm'ными.
     
  • 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.
     
     
  • 5.65, Антоним (?), 13:48, 10/06/2011 [^] [^^] [^^^] [ответить]  
  • –2 +/
    ну да, поддержка называется mount -o remount,ro. Очень круто.
     
     
  • 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.

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

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

     
  • 2.49, Онаним (?), 11:32, 09/06/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Что не так? Снапшоты бакапы не отменяют. Или Вы не в курсе?
     

  • 1.50, metallic (ok), 11:58, 09/06/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Они бы лучше утилиты допилили, а то срам.
     
     
  • 2.57, anonymous (??), 12:47, 09/06/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Они бы лучше утилиты допилили, а то срам.

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

     
     
  • 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-ом повреждений файловой системы происходит част... большой текст свёрнут, показать
     
  • 3.72, iZEN (ok), 16:32, 10/06/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > А потом бравые бсдшники собирают свои ZFSные пулы чуть ли не хексэдитором.
    > Чья бы мычала, с своими практически отсутствующими тулзами для восстановления тяжело
    > разрушенной ФС.

    Было: http://www.lissyara.su/articles/freebsd/file_system/zfs_recovery/
    Стало: http://www.mail-archive.com/freebsd-stable@freebsd.org/msg116307.html
    ---
    - zpool import -F. Allows to rewind corrupted pool to earlier
      transaction group
    - possibility to import pool in read-only mode
    ---

     
     
  • 4.78, Аноним (-), 00:19, 13/06/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Было: http://www.lissyara.su/articles/freebsd/file_system/zfs_recovery/
    > Стало: http://www.mail-archive.com/freebsd-stable@freebsd.org/msg116307.html

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

     
  • 2.70, qux (ok), 16:18, 10/06/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > да еще с отключеным проверкой данных (только метадынные проверяются) будет априори
    > быстрее zfs. Ну что же, комуто важна скорость в ущерб функционала.

    http://66.135.57.166/lists/linux-ext4/msg24047.html

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

     
     
  • 3.75, yalur (ok), 17:52, 10/06/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > http://66.135.57.166/lists/linux-ext4/msg24047.html

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

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

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

     
     
  • 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 буду и далее, вместе они позволяют очень гибко управлять дисковым пространством.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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