| 1.1, Аноним (-), 16:44, 19/11/2006 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
>Плавающий размер блоков, начиная с 512 байт.
Вот это гуд. Надо будет попробовать поиграться. | | |
| |
| 2.5, Alant (?), 20:08, 19/11/2006 [^] [^^] [^^^] [ответить]
| +/– | |
Интересно, что придумал автор links уже в качестве PhD ;-) | | |
|
| |
| 2.3, pavlinux (??), 19:46, 19/11/2006 [^] [^^] [^^^] [ответить]
| +/– |
 ... но систему нагружает неподецки:
При вот такой команде - localhost:/ # bonnie++ -d /media/test -u 0:0
Даже фаярфокс висел, ожидая очередного sync_а
На Reiser4 и XFS - такого нет.
| | |
|
| 1.6, gmm20 (?), 02:35, 20/11/2006 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
у этой системы слишком жесткие требования к жестким дискам:
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 ей еще очень далеко в плане надежности. | | |
| 1.11, nuclight (?), 10:41, 20/11/2006 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Почитал про ейные 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.12, Дмитрий ю. Карпов (?), 20:30, 20/11/2006 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
1) Хочу файловую систему с компрессией данных.
2) Хочу, чтобы можно было указать для редкоизменяемых разделов (типа /usr) "класть файлы плотно", дабы меньше гонять головки и увеличить эффективность упреждающего считывания.
3) И наконец, хочу дефрагментатор, которому я могу указать, как разместить файлы (как у Нортона). Например, я хочу, чтобы все директории раздела лежали вместе.
А вот что касается неэффективности хэширования, то я не согласен - никто не мешает строить B-tree для элементов, попавших в коллизию (т.е. из каждого hash-ключа растёт B-tree). | | |
| |
| 2.13, elendal (?), 02:10, 21/11/2006 [^] [^^] [^^^] [ответить]
| +/– |
1) Хочу файловую систему с компрессией данных.
ZFS vrode podderzhivaet
2,3) erunda. | | |
| 2.14, Аноним (-), 00:17, 22/11/2006 [^] [^^] [^^^] [ответить]
| +/– |
>1) Хочу файловую систему с компрессией данных.
...
Похвально.Я еще хочу выделение ровно размера файла на размер файла.Какого черта 20-байтный файл должен трескать 512...65536 байт?(slack при хранении 20-байтного файла 512/20 = в 25.5 раз!Опупеть эффективность ФС, ага...).Рейзер мог бы стать такой ФС, но...
1) Слишком сложный.Слишком навороченный.Почти нереально отладить ЭТО до состояния стабильности и надежности которую все хотят от современной фс.
2) Рейзер явно кому-то мешал и его нечаянно так подставили, чтобы он нечаянно не сделал слишком хорошую файловую систему.Потому что в рейзер 4 почти все что вы описываете есть...или предусмотрено на будущее. | | |
|
|
