https://www.opennet.ru/openforum/vsluhforumID3/55372.html "NILFS: A File System to Make SSDs Scream (http://www.linux-mag.com/id/7345/)" - обзор особо устойчивая к сбоям файловой системы NILFS2 (http://www.nilfs.org/en/), которая будет включена в состав Linux ядра 2.6.30. Для хранения всех данных в NILFS2 используются подобные логам структуры, в которых только добавляются новые записи и никогда не переписываются активные. Таким образом оборванная крахом операция записи, никак не отразится на целостности хранимых данных. В NILFS используются B-tree деревья и 64-битные структуры данных, поддерживается возможность фиксации снапшотов (контрольных точек в логе) для просмотра состояния данных на определенный момент времени. Более того с данными в снапшотах можно продолжать работать как с альтернативной веткой ФС, существующей параллельно.<br><br>URL: http://www.linux-mag.com/id/7345/<br>Новость: http://www.opennet.ru/opennews/art.shtml?num=22015<br> https://www.opennet.ru/openforum/vsluhforumID3/55372.html#35 Sat, 06 Jun 2009 02:17:33 GMT &gt;Да. <br><br>Точно, давайте все "версионники" будем валить в кучу :).Ведь идея в основе их работы одинаковая :)<br> https://www.opennet.ru/openforum/vsluhforumID3/55372.html#34 Sat, 06 Jun 2009 02:16:16 GMT &gt;Btrfs уже не нужна - ZFS уже давно в лапах Оракля <br><br>Во первых, btrfs по своей задумке будет уметь ряд плюшек которые ZFS не умеет(и неизвестно будет ли уметь).<br><br>Во вторых, очень интересно смотрится заява "ZFS уже давно в лапах Оракля" - а что, сделка уже окончательно и бесповоротно завершена?А чего тогда сан до сих пор выступает не под брендом Оракл а под своим?<br><br>В третьих - советую подумать о том что линукс столько лет жил вообще без оракла.А вот то что оракл вообще захочет долговременно тягать развитие соляры (и ZFS) в 1 рыло - как-бы не факт.Это куда дороже и геморнее чем совместная разработка с размазыванием затрат на всю ораву.А сил кроме оракла способных работать над такой системой как-то не видно.Тут сан сам себя в пятку своим жлобством по части монопольного контроля развития системы подстрелил, имхо.Они это поняли, но выправить ситуацию не успели.И как известно, Sun хоть и обладал большими доходами, обладал и большими расходами.<br> https://www.opennet.ru/openforum/vsluhforumID3/55372.html#33 Sat, 06 Jun 2009 02:06:26 GMT &gt;Ура в Linux снова изобрели ZFS<br><br>Это не ZFS, NILFS явно менее наворочен.На функциональный аналог ZFS больше BTRFS смахивает, местами по задумке даже переплевывая оный.<br> https://www.opennet.ru/openforum/vsluhforumID3/55372.html#32 Sat, 06 Jun 2009 01:59:45 GMT &gt;К тому времени мы все поседеем и умрём,<br><br>Что-то мне не хотелось бы так быстро подохнуть. Чтобы помереть за считанные годы наверное надо жить на свалке ядерных отходов и ядохимикатов?...<br> https://www.opennet.ru/openforum/vsluhforumID3/55372.html#31 Sat, 06 Jun 2009 01:56:58 GMT &gt;будет. у них бабки <br><br>Ну да, анонимам конечно виднее :).А чего тогда Chris Mason из оракла ничего такого не говорит про пиндец и во всех интервью утверждает что btrfs-у - быть?Может и правда у оракла бабки есть и потому на зарплату одному своему програмеру при потенциально интересном для их бизнеса результате они явно могут денег наскрести? :)<br> https://www.opennet.ru/openforum/vsluhforumID3/55372.html#30 Sat, 06 Jun 2009 01:54:15 GMT &gt;Что-то я сомневаюсь, что она не теряет в скорости. Почему ты думаешь, <br>&gt;что она должна быть быстрее обычной ФС c журналированием? <br><br>В обычной ФС если честно журналить и метаданные ФС и данные файлов, придется писать записываемые данные 2 раза. Сперва в журнал, потом в ФС. Двойная запись данных разумеется сажает скорость записи. Зато честно реализуется "все или ничего".Запись аннулируется если обломалась при записи в журнал или доводится до конца по данным из журнала если обломалась уже при записи в основную ФС.<br><br>Обычно такая просадка считается неприемлимой (просадка вдвое, плюс-минус лапоть) и для большинства некритичных задач пользуют компромиссные варианты, когда в журнал идут только метаданные.Цена компромисса - честного "все или ничего" уже не получается.Валидное состояние ФС - да, есть.А вот в каком состоянии файлы?Правильно, никто ничего не гарантирует.Грамотный подход (типа ordered в ext3) может помочь данным оставаться более-менее корректными в типовых сценариях.Но честные транзакции через журнал https://www.opennet.ru/openforum/vsluhforumID3/55372.html#29 Sat, 06 Jun 2009 00:59:36 GMT &gt;тут тот же принцип, что в ZFS и btrfs, только реализация немного <br>&gt;проще. читайте про эти ФС -- станет понятнее. <br><br>Кстати, из того что мне интересно:<br>1) Перестройка+дефрагментеж GCом... а насколько это безопасно?В плане сохранности данных?По наблюдениям - сбои в процессе таких объединений-дефрагментаций - наиболее хреновое что может произойти с подобной структурой.Как с этим борятся?Что-то не нашел у NILFS на сайте внятного освещения этого вопроса(плохо искал?).<br>2) Если нагрузка постоянная и интенсивная - как это с GC будет уживаться?<br>3) Такие структуры в принципе склонны к фрагментации? (GC как я понимаю с этим должен бороться).<br>4) Конеретно у NILFS кажется работа с мелочью и большим числом файлов в каталогах сделана как я понимаю не ахти? Явно не выглядит как ФС для хранения миллионов мелких файлов в 1 дире в данный момент.<br> https://www.opennet.ru/openforum/vsluhforumID3/55372.html#28 Fri, 05 Jun 2009 20:18:41 GMT Да.<br> https://www.opennet.ru/openforum/vsluhforumID3/55372.html#27 Thu, 04 Jun 2009 18:17:33 GMT Угу, причем лицензия линукса.<br>