Почитал про ейные 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, непонятно,
Вариант для распечатки
Разговоры, обсуждение новостей (Public)
on 19-Ноя-06, 16:44 
