The OpenNET Project / Index page

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

Обзор файловой системы NILFS2, которая будет включена в состав Linux ядра 2.6.30

03.06.2009 21:42

"NILFS: A File System to Make SSDs Scream" - обзор особо устойчивой к сбоям файловой системы NILFS2, которая будет включена в состав Linux ядра 2.6.30. Для хранения всех данных в NILFS2 используются подобные логам структуры, в которых только добавляются новые записи и никогда не переписываются активные. Таким образом оборванная крахом операция записи, никак не отразится на целостности хранимых данных. В NILFS используются B-tree деревья и 64-битные структуры данных, поддерживается возможность фиксации снапшотов (контрольных точек в логе) для просмотра состояния данных на определенный момент времени. Более того с данными в снапшотах можно продолжать работать как с альтернативной веткой ФС, существующей параллельно.

  1. Главная ссылка к новости (http://www.linux-mag.com/id/73...)
  2. OpenNews: Завершено включение новых функций в Linux ядро 2.6.30. Добавлены 3 новые ФС
  3. OpenNews: Решение проблемы с потерей данных в ext4. NILFS2 и CEPH претендуют на включение в ядро 2.6.30
  4. OpenNews: Новая, устойчивая к сбоям, файловая система для Linux
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/22015-NILFS
Ключевые слова: NILFS, linux, kernel, NILFS2
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (35) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, User294 (ok), 23:31, 03/06/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +7 +/
    Кому-то явно завидно что в юбилейном 30-м ядре будет еще одна не самая плохая ФС :).Поставили понимаешь новости -1 втихарика, подлые трусы :Е.
     
  • 1.2, Аноним (-), 23:34, 03/06/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    так снапшоты можно ведь через LVM реализовать. нужна ли тогда для этих функций новая ФС? не считая независимых деревьев, конечно.
     
     
  • 2.3, User294 (ok), 23:47, 03/06/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >так снапшоты можно ведь через LVM реализовать. нужна ли тогда для этих
    >функций новая ФС? не считая независимых деревьев, конечно.

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

    ЗЫ в этой статье ext2 почему-то обозвана ФС с деревьями.Если я не дятел - они гонят.Чистый ext2 без нифига деревьями вроде не пользуется?!

    ЗЗЫ видится интересный вариант рекавери системы с такой ФС - просто загрузиться в состояние (снапшот) на энное время раньше.Нечто типа отката состояния у виртуалки :)

     
     
  • 3.6, Аноним (-), 00:50, 04/06/2009 [^] [^^] [^^^] [ответить]  
  • +/
    но как я понимаю, версионные ФС создают большую избыточность данных, чтобы хранить одни и те же файлы, но разных версий. скорее всего используется какая-либо инкрементальная разница между снапшотами для уменьшения использования дискового пространства.

    правильно понимаю?

     
     
  • 4.9, User294 (ok), 02:01, 04/06/2009 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Версионники не переносят логи изменений из журнала в основную ФС в отличие от об... большой текст свёрнут, показать
     
     
  • 5.10, Аноним (-), 05:42, 04/06/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Новое состояние = старое + логи.

    Непонятен этот момент. Т.е. текущее состояние - это лог1 + лог2 + лог3 + ... логХХХХ ? Если так, то считывать тысячи разниц, и, плюс к тому, сравнивать их - довольно затратно.

    Или всё же после нескольких десятков изменений создаётся снимок состояний, который достаточно один раз прочитать и сразу использовать, без необходимости сравнивать разницы? Заранее спасибо :)

     
     
  • 6.21, fresco (??), 13:01, 04/06/2009 [^] [^^] [^^^] [ответить]  
  • +/
    тут тот же принцип, что в ZFS и btrfs, только реализация немного проще. читайте про эти ФС -- станет понятнее.
     
     
  • 7.29, User294 (ok), 04:59, 06/06/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >тут тот же принцип, что в ZFS и btrfs, только реализация немного
    >проще. читайте про эти ФС -- станет понятнее.

    Кстати, из того что мне интересно:
    1) Перестройка+дефрагментеж GCом... а насколько это безопасно?В плане сохранности данных?По наблюдениям - сбои в процессе таких объединений-дефрагментаций - наиболее хреновое что может произойти с подобной структурой.Как с этим борятся?Что-то не нашел у NILFS на сайте внятного освещения этого вопроса(плохо искал?).
    2) Если нагрузка постоянная и интенсивная - как это с GC будет уживаться?
    3) Такие структуры в принципе склонны к фрагментации? (GC как я понимаю с этим должен бороться).
    4) Конеретно у NILFS кажется работа с мелочью и большим числом файлов в каталогах сделана как я понимаю не ахти? Явно не выглядит как ФС для хранения миллионов мелких файлов в 1 дире в данный момент.

     
  • 5.18, xxx (??), 11:56, 04/06/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Основной плюс как я понимаю возможность честно журналировать запись и данных файлов и >метаданных не теряя от этого в скорости

    Что-то я сомневаюсь, что она не теряет в скорости. Почему ты думаешь, что она должна быть быстрее обычной ФС c журналированием?

     
     
  • 6.30, User294 (ok), 05:54, 06/06/2009 [^] [^^] [^^^] [ответить]  
  • +/
    В обычной ФС если честно журналить и метаданные ФС и данные файлов, придется пис... большой текст свёрнут, показать
     
  • 2.5, Аноним (-), 00:47, 04/06/2009 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >так снапшоты можно ведь через LVM реализовать. нужна ли тогда для этих
    >функций новая ФС? не считая независимых деревьев, конечно.

    на LVM не работают барьеры если используется больше одного физического диска, отсюда как следствие у программ и у ФС пишущих через LVM нет гарантии что после выхода из *sync() данные действительно записались на диск, а это может привести к повреждению данных или журнала ФС при неожиданном отключении питания.

    поэтому эта ФС нужна, а LVM не всегда можно использовать.

     
     
  • 3.7, Аноним (-), 00:52, 04/06/2009 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >на LVM не работают барьеры если используется больше одного физического диска

    что такое барьеры? с LMV я совсем недавно начал знакомиться.

     
     
  • 4.8, Аноним (-), 01:49, 04/06/2009 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >>на LVM не работают барьеры если используется больше одного физического диска
    >
    >что такое барьеры? с LMV я совсем недавно начал знакомиться.

    /usr/src/linux/Documentation/block/barrier.txt

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

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

     

  • 1.4, Аноним (-), 23:50, 03/06/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Нужна. LVM-snapshot - настолько общая вещь, что она неэффективна. Кроме того, NILFS2 должна будет внущать больше доверия к надёжности в плохих условиях, чем LVM.
     
  • 1.11, Аноним (-), 07:01, 04/06/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Ура в Linux снова изобрели ZFS, когда же наконец просто возьмут и будут использовать ZFS?
     
     
  • 2.12, Sonic (??), 08:54, 04/06/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Ура в Linux снова изобрели ZFS, когда же наконец просто возьмут и
    >будут использовать ZFS?

    Никогда. Лицензия же.

     
     
  • 3.27, аноним (?), 22:17, 04/06/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Угу, причем лицензия линукса.
     
  • 2.13, MaMoHT (?), 09:11, 04/06/2009 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Ура в Linux снова изобрели ZFS, когда же наконец просто возьмут и
    >будут использовать ZFS?

    Когда BRTFS допишут ZFS уже будет не нужна :-)

     
     
  • 3.16, osintsev (?), 10:15, 04/06/2009 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Btrfs уже не нужна - ZFS уже давно в лапах Оракля
     
     
  • 4.24, СуперАноним (?), 18:52, 04/06/2009 [^] [^^] [^^^] [ответить]  
  • +/
    А Оракль, что, уже в меинтейнеры линуксового ядра записался и будет решать, что нужно?
     
     
  • 5.25, аноним (?), 19:01, 04/06/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >будет решать, что нужно?

    будет. у них бабки

     
     
  • 6.31, User294 (ok), 05:56, 06/06/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >будет. у них бабки

    Ну да, анонимам конечно виднее :).А чего тогда Chris Mason из оракла ничего такого не говорит про пиндец и во всех интервью утверждает что btrfs-у - быть?Может и правда у оракла бабки есть и потому на зарплату одному своему програмеру при потенциально интересном для их бизнеса результате они явно могут денег наскрести? :)

     
  • 4.34, User294 (ok), 06:16, 06/06/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Btrfs уже не нужна - ZFS уже давно в лапах Оракля

    Во первых, btrfs по своей задумке будет уметь ряд плюшек которые ZFS не умеет(и неизвестно будет ли уметь).

    Во вторых, очень интересно смотрится заява "ZFS уже давно в лапах Оракля" - а что, сделка уже окончательно и бесповоротно завершена?А чего тогда сан до сих пор выступает не под брендом Оракл а под своим?

    В третьих - советую подумать о том что линукс столько лет жил вообще без оракла.А вот то что оракл вообще захочет долговременно тягать развитие соляры (и ZFS) в 1 рыло - как-бы не факт.Это куда дороже и геморнее чем совместная разработка с размазыванием затрат на всю ораву.А сил кроме оракла способных работать над такой системой как-то не видно.Тут сан сам себя в пятку своим жлобством по части монопольного контроля развития системы подстрелил, имхо.Они это поняли, но выправить ситуацию не успели.И как известно, Sun хоть и обладал большими доходами, обладал и большими расходами.

     
  • 2.33, User294 (ok), 06:06, 06/06/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Ура в Linux снова изобрели ZFS

    Это не ZFS, NILFS явно менее наворочен.На функциональный аналог ZFS больше BTRFS смахивает, местами по задумке даже переплевывая оный.

     

  • 1.14, Аноним (-), 09:42, 04/06/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Никогда. Лицензия же.

    Дык нынче Oracle у руля, он может и сменить на GPL2 лицензию, в добавок к CDDL.

     
     
  • 2.17, szh (ok), 10:17, 04/06/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >> Никогда. Лицензия же.
    >
    >Дык нынче Oracle у руля, он может и сменить на GPL2 лицензию,
    >в добавок к CDDL.

    может, но не сменил.

     
     
  • 3.20, fresco (??), 12:59, 04/06/2009 [^] [^^] [^^^] [ответить]  
  • +/
    и не сменит. там патенты, не совместимые с GPL. забудьте.
     
  • 3.26, Аноним (-), 20:00, 04/06/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >>> Никогда. Лицензия же.
    >>
    >>Дык нынче Oracle у руля, он может и сменить на GPL2 лицензию,
    >>в добавок к CDDL.
    >
    >может, но не сменил.

    Дык не является он пока официальным её владельцем, как купит SUN, так и сможет сменить, а пока он только может подруливать, но не рулить, ждём августа.

     

  • 1.15, Аноним (-), 09:44, 04/06/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Когда BRTFS допишут ZFS уже будет не нужна :-)

    К тому времени мы все поседеем и умрём, а вообще Oracle в случае покупки SUN, может просто отправить сию FS в аналы истории...комунити, как уже не раз делалось в опенсорсе, на вроде ReiserFS.

     
     
  • 2.32, User294 (ok), 05:59, 06/06/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >К тому времени мы все поседеем и умрём,

    Что-то мне не хотелось бы так быстро подохнуть. Чтобы помереть за считанные годы наверное надо жить на свалке ядерных отходов и ядохимикатов?...

     

  • 1.19, Frank (??), 12:37, 04/06/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    "Для хранения всех данных в NILFS2 используются подобные логам структуры, в которых только добавляются новые записи и никогда не переписываются активные."
    - эт как понять? Если я запишу на винт из сети надцать гигабайт фильмов, закатаю их на ДВД и удалю с винта, что - эти надцать гигабайт будут вечно заняты? :)
     
     
  • 2.22, mma (?), 13:11, 04/06/2009 [^] [^^] [^^^] [ответить]  
  • +/
    они будут помечены как свободные и со временем будут перезаписываться новыми данными по мере устаревания. А пока не перезаписались сохраняется версионость ФС в рамках данных файлов.
     

  • 1.23, Myc (??), 17:31, 04/06/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Это что 64-х битная реинкорнация BSD LFS?
     
     
  • 2.28, eve (?), 00:18, 06/06/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Да.
     
     
  • 3.35, User294 (ok), 06:17, 06/06/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Да.

    Точно, давайте все "версионники" будем валить в кучу :).Ведь идея в основе их работы одинаковая :)

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



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

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