Даже пользователь без прав администратора способен вызвать необратимую рассинхронизацию дисков.
В Linux обнаружена серьёзная уязвимость, существующая уже более десяти лет, и связана она с механизмом программного RAID при использовании флага O_DIRECT. Проблема позволяет привести массив в несогласованное состояние, причём без каких-либо ошибок или предупреждений со стороны системы. Несмотря на то, что баг впервые был зарегистрирован ещё в 2015 году, интерес к нему вновь возрос в контексте современных задач, таких как живая миграция виртуальных машин.
Реализация 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 требует для хранения журнала больше памяти и уступает в быстродействии.
Daniel Phillips анонсировал выход Tux3. Tux3 является продолжением развития Tux2, файловой системы, которая за 10 лет разработки так не была анонсирована официально. Это версионная файловая система с поддержкой B-деревьев, атомарных коммитов и "записи повсюду". Частью работы является улучшенная поддержка хэш-индексирования (htree) каталогов.
В отличие от рекурсивного "copy on write" с одним корнем на дерево на версию, Tux3 сохраняет всю версионированую информацию в конечных нодах B-деревьев. Алгоритм (подробнее) позволил значительно сократить метаданные по сравнению с ZFS и Btrfs.
Характеристики и ограничения файловой системы:
Отдельное версионирование для файлов, директорий и всей файловой системы.
Поддержка реплицирования отдельных локальныйх файлов, директорий и всей файловой системы на удаленную машину.
Поддержка записи во все версии (снэпшоты).
2^60 — максимальный размер файла.
2^60 — максимальный размер раздела.
2^48 — максимальное количество версий.
2^48 — максимальное количество нодов.
Легкое масштабирование и динамическое выделение инодов.
Новые методы версионирования.
Новый метод атомарного обновления.
Новый стабильный индекс директорий (PHTree).
Использование указателей изменений в B-tree для более надежной работы fsck.
Вышла первая версия драйвера файловой системы для использования на хранилищах малоценной информации. Драйвер работает под управлением FUSE и позволяет реализовать прозрачное объединение нескольких файловых систем в одну.
В отличие от известных аналогов, выполняющих те же действия, этот драйвер умеет монтировать множество файловых систем в режиме rw (с системой unionfs, например, подобный эффект достигается применением внешнего демона).
В случае, если запись, ведущаяся на носитель X заканчивается неудачей из-за нехватки места на носителе, драйвер перенесет уже записанные данные на носитель, где этого места достаточно. Таким образом можно сэмулировать файловую систему очень большого размера.
P.S. В продолжение споров в Talks: подобную функциональность легко реализовать с использованием технологий RAID/LVM и т.п. Однако в этом случае функциональность будет реализована на низком уровне "под" файловыми системами, что приводит к сложностям извлечения (добавления) из (в) системы новых носителей.
