Всего сообщений: 4
Реализация XFS в ядре 5.10 решит проблему 2038 года до 2486 года, в ней реализованы «большие даты». Сейчас дата у файла не может быть больше, чем 2038 год, что, конечно, не завтра, но и не через 50 лет. Изменение откладывает проблему на 4 века, что приемлемо на нынешнем уровне развития технологий.
>>> Подробности
В основную ветку разработки FreeBSD-CURRENT (будущая основа следующего релиза FreeBSD 9.0) были внесены патчи, реализующие поддержку журналирования Soft Updates для основной файловой системы FreeBSD — UFS. Для реализации этой возможности было добавлено 11 тысяч строк кода и 2 тысячи было удалено. Максимальный размер журнала составляет 32 Мб, хранящие в себе записи о последнем миллионе операций (информация об одной операции составляет 32 байта). Спонсорами разработки являются такие крупные компании как iXsystems, Yahoo! и Juniper.
Журналирование метаданных, изменяемых при работе Soft Updates (SU+J), позволит отказаться от необходимости фонового запуска fsck после некорректного отключения файловой системы (при аппаратном сбое или отключении подачи электроэнергии, например) и достичь довольно высокой скорости восстановления состояния файловой системы при достаточно малом объеме журнала, файловая система остается полностью обратно совместимой с нежурналируемым вариантом softupdates. Для примера: процесс восстановления после экстренного отключения заполненного на 80% дискового раздела, размером 250 Гб, с использованием SU+J занял менее секунды, в то время как без SU+J обычный fsck восстанавливал целостность данных 24 (!) минуты.
Ранее журналирование для файловой системы FreeBSD реализовывалось при помощи GEOM-класса gjournal и было доступно только на уровне GEOM провайдеров. Основное отличие gjournal от SU+J в том, что первый работает на уровне блочного устройства, в то время как второй манипулирует данными только на уровне мета-данных файловой системы. Как следствие gjournal требует для хранения журнала больше памяти и уступает в быстродействии.
Новость является перепечаткой новости с сайта http://www.opennet.ru
Daniel Phillips анонсировал выход Tux3. Tux3 является продолжением развития Tux2, файловой системы, которая за 10 лет разработки так не была анонсирована официально. Это версионная файловая система с поддержкой B-деревьев, атомарных коммитов и "записи повсюду". Частью работы является улучшенная поддержка хэш-индексирования (htree) каталогов.
В отличие от рекурсивного "copy on write" с одним корнем на дерево на версию, Tux3 сохраняет всю версионированую информацию в конечных нодах B-деревьев. Алгоритм (подробнее) позволил значительно сократить метаданные по сравнению с ZFS и Btrfs.
Характеристики и ограничения файловой системы:
>>> Подробности
Вышла первая версия драйвера файловой системы для использования на хранилищах малоценной информации. Драйвер работает под управлением FUSE и позволяет реализовать прозрачное объединение нескольких файловых систем в одну.
В отличие от известных аналогов, выполняющих те же действия, этот драйвер умеет монтировать множество файловых систем в режиме rw (с системой unionfs, например, подобный эффект достигается применением внешнего демона).
В случае, если запись, ведущаяся на носитель X заканчивается неудачей из-за нехватки места на носителе, драйвер перенесет уже записанные данные на носитель, где этого места достаточно. Таким образом можно сэмулировать файловую систему очень большого размера.
P.S. В продолжение споров в Talks: подобную функциональность легко реализовать с использованием технологий RAID/LVM и т.п. Однако в этом случае функциональность будет реализована на низком уровне "под" файловыми системами, что приводит к сложностям извлечения (добавления) из (в) системы новых носителей.