LINUX.ORG.RU

Новая файловая система для Linux с поддержкой снапшотов

 , ,


0

0

Компания CTERA Networks, специализирующаяся на разработке гибридных облачных систем хранения данных, представила новую файловую систему для Linux - Next3, основанную на коде Ext3 и расширяющую её возможности поддержкой снапшотов.

По сравнению с решениями, использующими снапшоты на базе LVM, Next3 обладает следующими преимуществами:

  • Снапшоты Next3 инкрементальны, не требуют предварительного резервирования места, что позволяет гибко управлять свободным дисковым пространством и значительно экономить место на диске.
  • Масштабируемость. Даже при огромном количестве снапшотов скорость Next3 остается на уровне, близком к ext3.
  • Легковесность. Снапшоты создаются и удаляются практически мгновенно, сразу же после удаления снапшота занимаемое им место автоматически освобождается.
  • Полная прямая и обратная совместимость с ext3, миграция осуществляется тремя командами - отмонтирование, настройка с помощью tune2fs, монтирование.

Next3 не накладывает никаких ограничений на количество и размер снапшотов, однако существует минимальный предел размера файловой системы — 4 Гб. Исходные коды проекта доступны под лицензией GNU GPL. В комплект входят два патча на ядро (для версии 2.6.32.12), патч для e2fsprogs и скрипт управления снапшотами.

Источник

>>> Подробности

Ответ на: комментарий от iZEN

оно вроде как для несколько других целей, хоть и включает в себя возможности сабжа

Fracta1L ()

>Даже при огромном количестве снапшотов скорость Next3 остается на уровне, близком к ext3.

скорость Next3 остается на уровне, близком к ext3.

я один чувствую подвох?

cuki ★★★★ ()
Ответ на: комментарий от yirk

> Очередное пополнение зоопарка.

Дык, The Bazaar software development model как он есть.

Manhunt ★★★★★ ()

Re: Новая файловая система для Linux с поддержкой снапшотов

Цитируем Fracta1Lannoynimous

Next3, основанную на коде Ext3

Остроумное название :)

power ()

Пока этого не будет в качестве опции дл дебиан и других дистрибутивов рассматривать что-то было бы глупостью.

libre ()

Какие преимущества и недостатки дает перенос снапшотов с уровня блочного устройства (LVM2) на уровень файловой системы (Next3, ZFS, btrfs) как таковой? Иными словами, это просто смешивание уровней абстракции и срезание углов, или все же осмысленное архитектурное решение, исправляющее принципиальные ошибки LVM2?

AEP ★★★★★ ()

Может быть совместимость с ext3 и достоинстово, но это ничуть не угрожает btrfs и zfs. Снепшоты не такая уж киллерфича, чтобы переплюнуть этих товарищей, у сами есть и не только.

vertexua ★★★★★ ()
Ответ на: комментарий от vertexua

> Снепшоты не такая уж киллерфича, чтобы переплюнуть этих товарищей

Однако может стать причиной отката с ext4, если всё-равно пох что выбирать.

anonymoos ★★★★★ ()

Принципиально новая?

anonymous ()

новость не читал, но осуждаю.

велосипед!

leg0las ★★★★★ ()

Теперь то точно вендекапец.

Ждем Next4.

Werehuman ★★ ()

Ну это здорово, конечно, но они малось опоздали, делая расширение для Ext3, когда уже есть и почти везде используется Ext4

Xenius ★★★★★ ()
Ответ на: комментарий от AEP

>Какие преимущества и недостатки дает перенос снапшотов с уровня блочного устройства (LVM2) на уровень файловой системы (Next3, ZFS, btrfs) как таковой? Иными словами, это просто смешивание уровней абстракции и срезание углов, или все же осмысленное архитектурное решение, исправляющее принципиальные ошибки LVM2?

Уменьшение оверхеда во многих местах, об этом писали как разработчики btrfs так и zfs. О каких принципиальных ошибках речь?

PS Хороший костыль, надеюсь стабильный.

aidaho ★★★★★ ()
Ответ на: комментарий от Fracta1L

>> так что ваши zfs с btrfs можно закопать

это примерно из той же оперы

kto_tama ★★★★★ ()
Ответ на: комментарий от aidaho

> О каких принципиальных ошибках речь?

Ни о каких конкретно. Собственно, мой вопрос касался их существования, Вы ответили ссылкой на оверхед. Спасибо.

AEP ★★★★★ ()
Ответ на: комментарий от cuki

я один чувствую подвох?

Да нет, они его даже не скрывают:

Sub-optimal performance

The following issues may cause performance degradation and should be further optimized: Move-on-write with random in-place writes to a large file causes file fragmentation and degrades sequential read performance. Next3 with N snapshots may use up to N+1 address spaces and N+1 pages to map the same unmodified block.

anonymous ()

профита от lvm'а несоизмеримо больше, чем оверхеда.
одни снапшоты ничего не меняют.

d9d9 ★★★ ()

Nbtrfs будет?

anonymous ()

я вовсе не предираюсь и рад за тех, кому оно нужно, но как так оно устроено, что миинимаальный размер файловой системы - четыре гигабайта!

jeuta ★★★★ ()
Ответ на: комментарий от jeuta

> но как так оно устроено, что миинимаальный размер файловой системы - четыре гигабайта!

Это что, много? Не терабайта же :)

Solaris10 ()

чего только ни придумают, чтобы zfs не портировать и btrfs не допиливать до вменяемого состояния

George ()

Кстати, подскажите пожалуйста, кто-нибудь знает о разработках файловых систем для Линукса, схожих по философии с Elephant FS? С историей изменений каждого отдельного файла, возможностью восстановления нужной версии, вплоть до начала создания и т.п..

anonymous ()

пусть к ext4 прикручивают, я согласен.

boo32 ()

А что у сабжа с надёжностью?

WARNING ★★★★ ()
Ответ на: комментарий от anonymous

>Кстати, подскажите пожалуйста, кто-нибудь знает о разработках файловых систем для Линукса, схожих по философии с Elephant FS? С историей изменений каждого отдельного файла, возможностью восстановления нужной версии, вплоть до начала создания и т.п..
Про Elephant FS не слыхал, но похоже, что вам нужно вот это: http://en.wikipedia.org/wiki/Versioning_filesystem . Там есть список проектов для линукса.

Laz ★★★★★ ()
Ответ на: комментарий от anonymous

А зачем такое извращение? Это ж бред с точки зрения архитектуры. Ну есть куча каких-то изменений. Как вы отследите, какое из них дает осмысленный результат, а какое - просто кусок большей операции? Версионность должна поддерживаться на более высоком уровне, чем FS. Фактически, это нужен новый набор интерфейсов работы с FS (и согласен, что это было бы весьма полезно - к примеру, copy как системный вызов, commit, который и означал бы существование логически корректной версии и т.д.)

crazy_alex ()
Ответ на: комментарий от anonymous

>историей изменений каждого отдельного файла, возможностью восстановления нужной версии, вплоть до начала создания и т.п..
Из похожего работает nilfs2, там снапшотится вся ФС во время каждого изменения. Все снапшоты ro, могут монтироваться. Старые снапшоты автоудаляются сборщиком мусора при нехватке места (кроме специально отмеченных).
Но проследить историю конкретного файла в ней сложно. Только целый снапшот.

x3al ★★★★★ ()
Ответ на: комментарий от Xenius

Xenius>когда уже есть и почти везде используется Ext4

блин... опять пацаны все проспали...

roller ★★★ ()
Ответ на: комментарий от Valmont

Миграция куда?

UFS2+SUJ на подходе же. Без ограничений на минимальный размер ФС.

iZEN ★★★★★ ()
Ответ на: комментарий от Fracta1L

>кастую тесты от DNA_Seq

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

Интересно, чем обусловлено ограничение на минимальный размер ФС?

DNA_Seq ★★☆☆☆ ()

Не понял кстати, почему оно позиционируется как замена LVM а производительность сравнивается с ext3? Это же вроде аналог zfs

DNA_Seq ★★☆☆☆ ()
Ответ на: комментарий от George

zfs не портируют из-за лицензионный ограничений, как юзерспейсный модуль через fuse доступна zfs давно. А по поводу состояния btrfs ждем камментов Silvy

DNA_Seq ★★☆☆☆ ()
Ответ на: комментарий от DNA_Seq

про порт zfs была новость недавно, про fuse знаю, конечно. но допилить btrfs было бы идеальным решением, вместо того, чтобы велосипеды плодить

George ()
Ответ на: комментарий от crazy_alex

> А зачем такое извращение? Это ж бред с точки зрения архитектуры. Ну есть куча каких-то изменений. Как вы отследите, какое из них дает осмысленный результат, а какое - просто кусок большей операции?

изменения не происходят абы как. там, где лежит /var - используем другую ФС, без заморочек, где лежат здоровенные медиа-файлы - XFS или JFS, к примеру. а вот /home я бы с удовольствием положил на ФС вроде Элефанта, т.к. мне не столько важно место (документ, размером несколько сотен килобайт - мелочь, учитывая размеры современных винтов), сколько возможность вернуть изменения, вплоть до удаления, перемещения или перезаписи файла (случайной или нет - не важно). а вот создавать для этот специализированное хранилище вроде SVN - бред. На уровне ФС и с точки зрения архитектуры ФС ничего не мешает реализовать, даже удобнее для пользователя, т.к. не приходится задумываться при любых операциях с файлами. (поднимите руки кто проклинал все на свете, удалив, перезаписав или еще как-то загубив очень нужный документ на стандартной ФС с журналированием, когда ни ноже, ни роже, ни названия ничего уже не найти... )

вот ссылка на сабж, кому интересно почитать: http://www.stanford.edu/class/cs240/readings/p110-santry.pdf

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.