Цель SpadFS (http://artax.karlin.mff.cuni.cz/~mikulas/spadfs/) - создание современной файловой системы без лишних усложнений и роста кодовой базы.
Из возможностей можно отметить:
- Для быстрого восстановления целостности после краха, вместо журналирования, используется технология "crash counts";
- Максимальный размер раздела до 144 PB.
- Плавающий размер блоков, начиная с 512 байт.
- Хэширвоание содержимого директорий (нет проблем с производительностью для директорий с огромным числом файлов).
URL: http://artax.karlin.mff.cuni.cz/~mikulas/spadfs/
Новость: http://www.opennet.me/opennews/art.shtml?num=8902
>Плавающий размер блоков, начиная с 512 байт.Вот это гуд. Надо будет попробовать поиграться.
Интересно, что придумал автор links уже в качестве PhD ;-)
Дык, а шустрая однако....
... но систему нагружает неподецки:
При вот такой команде - localhost:/ # bonnie++ -d /media/test -u 0:0
Даже фаярфокс висел, ожидая очередного sync_а
На Reiser4 и XFS - такого нет.
Диагноз: пока НЕПРЕЕМПТЕБЛНАЯ (preemptible) :)
у этой системы слишком жесткие требования к жестким дискам:Requirements
------------
Disk that can atomically write one sector (512 bytes) so that the sector
contains either old or new content in case of crash.это не выполняется ни с одним современным ATA/SATA диском.
не уверен, что и все SCSI/SAS без UPS могут гарантировать
выполенние этого условия.вывод: до ext3 ей еще очень далеко в плане надежности.
Почитал про ейные internals. Не фонтан.В новости сказано "Плавающий размер блоков, начиная с 512 байт" - тут не ясно, речь то ли об экстентах, то ли "Variable block size from 512 bytes to machine page size" - то, что уже есть... кстати, размер страницы (4К на x86) для некоторых случаев маловат будет.
Filesystem has current crash count [disk_cc], that is incremented with each mount and decremented with each unmount (thus, it counts crashes) ... New entries are written with values (entry->cc = memory_cc, entry->txc = memory_cct). So they are seen as valid in current directory scans, but in case of crash, disk will contain one-less value: disk_cc[entry_cct] == entry->txc - 1, so they will be invalid.
Попросту говоря, всё, что было создано, переименовано etc. между монтированиями - будет просто потеряно нафиг. Что при больших аптаймах довольно неприятно. Конечно, это наверняка будет переделано от монтирований до sync'ов - но временные промежутки между sync'ами опять-таки могут быть очень велики, причем появляется значительный оверхед на скан/апдейт ВСЕХ структур на диске при sync'е. А значит, раздел с большим количеством файлов нехило так подвиснет при этом.
Что мешало придумать что-нибудь вроде фрёвых софтапдейтов, непонятно.
Дальше, инодов нет, а fnode_block has 512 bytes - такой здоровый, а занят непонятно чем. Из отсутствия инодов следует необходимость эмуляции хардлинков несколькими fnode'ами -> усложнение кода. Используется хэширование, а не B-tree, в результате при коллизиях оно становится весьма неэффективным, плюс дополнительные сложности кодеру при реализации указателей на текущую позицию для стандартных функций (telldir(), seekdir(), etc.). Что мешало свистнуть идею из NTFS, непонятно,
1) Хочу файловую систему с компрессией данных.2) Хочу, чтобы можно было указать для редкоизменяемых разделов (типа /usr) "класть файлы плотно", дабы меньше гонять головки и увеличить эффективность упреждающего считывания.
3) И наконец, хочу дефрагментатор, которому я могу указать, как разместить файлы (как у Нортона). Например, я хочу, чтобы все директории раздела лежали вместе.
А вот что касается неэффективности хэширования, то я не согласен - никто не мешает строить B-tree для элементов, попавших в коллизию (т.е. из каждого hash-ключа растёт B-tree).
1) Хочу файловую систему с компрессией данных.
ZFS vrode podderzhivaet
2,3) erunda.
>1) Хочу файловую систему с компрессией данных.
...
Похвально.Я еще хочу выделение ровно размера файла на размер файла.Какого черта 20-байтный файл должен трескать 512...65536 байт?(slack при хранении 20-байтного файла 512/20 = в 25.5 раз!Опупеть эффективность ФС, ага...).Рейзер мог бы стать такой ФС, но...
1) Слишком сложный.Слишком навороченный.Почти нереально отладить ЭТО до состояния стабильности и надежности которую все хотят от современной фс.
2) Рейзер явно кому-то мешал и его нечаянно так подставили, чтобы он нечаянно не сделал слишком хорошую файловую систему.Потому что в рейзер 4 почти все что вы описываете есть...или предусмотрено на будущее.