The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка  RSS
"OpenNews: Spad - новая экспериментальная файловая система дл..."
Вариант для распечатки  
Пред. тема | След. тема 
Форумы Разговоры, обсуждение новостей (Public)
Изначальное сообщение [Проследить за развитием треда]

"OpenNews: Spad - новая экспериментальная файловая система дл..."  
Сообщение от opennews on 19-Ноя-06, 16:44 
Цель 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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

 Оглавление

Сообщения по теме [Сортировка по времени, UBB]


1. "Spad - новая экспериментальная файловая система для Linux"  
Сообщение от Аноним on 19-Ноя-06, 16:44 
>Плавающий размер блоков, начиная с 512 байт.

Вот это гуд. Надо будет попробовать поиграться.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

5. "Spad - новая экспериментальная файловая система для Linux"  
Сообщение от Alant on 19-Ноя-06, 20:08 
Интересно, что придумал автор links уже в качестве PhD ;-)
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "Spad - новая экспериментальная файловая система для Linux"  
Сообщение от pavlinux email(??) on 19-Ноя-06, 19:27 
Дык, а шустрая однако....
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "Spad - новая экспериментальная файловая система для Linux"  
Сообщение от pavlinux email(??) on 19-Ноя-06, 19:46 
... но систему нагружает неподецки:
При вот такой команде - localhost:/ # bonnie++ -d /media/test -u 0:0
Даже фаярфокс висел, ожидая очередного sync_а
На Reiser4 и XFS - такого нет.


Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

4. "Spad - новая экспериментальная файловая система для Linux"  
Сообщение от pavlinux email(??) on 19-Ноя-06, 19:50 
Диагноз: пока НЕПРЕЕМПТЕБЛНАЯ (preemptible) :)
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

6. "не для IDE или нужен UPS"  
Сообщение от gmm20 on 20-Ноя-06, 02:35 
у этой системы слишком жесткие требования к жестким дискам:

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 ей еще очень далеко в плане надежности.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

11. "Spad - новая экспериментальная файловая система для Linux"  
Сообщение от nuclight email on 20-Ноя-06, 10:41 
Почитал про ейные 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, непонятно,

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

12. "Я бы хотел другого"  
Сообщение от Дмитрий ю. Карпов on 20-Ноя-06, 20:30 
1) Хочу файловую систему с компрессией данных.

2) Хочу, чтобы можно было указать для редкоизменяемых разделов (типа /usr) "класть файлы плотно", дабы меньше гонять головки и увеличить эффективность упреждающего считывания.

3) И наконец, хочу дефрагментатор, которому я могу указать, как разместить файлы (как у Нортона). Например, я хочу, чтобы все директории раздела лежали вместе.

А вот что касается неэффективности хэширования, то я не согласен - никто не мешает строить B-tree для элементов, попавших в коллизию (т.е. из каждого hash-ключа растёт B-tree).

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

13. "Я бы хотел другого"  
Сообщение от elendal on 21-Ноя-06, 02:10 
1) Хочу файловую систему с компрессией данных.
    ZFS vrode podderzhivaet
2,3) erunda.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

14. "Я бы хотел другого"  
Сообщение от Аноним on 22-Ноя-06, 00:17 
>1) Хочу файловую систему с компрессией данных.
...
Похвально.Я еще хочу выделение ровно размера файла на размер файла.Какого черта 20-байтный файл должен трескать 512...65536 байт?(slack при хранении 20-байтного файла 512/20 = в 25.5 раз!Опупеть эффективность ФС, ага...).Рейзер мог бы стать такой ФС, но...
1) Слишком сложный.Слишком навороченный.Почти нереально отладить ЭТО до состояния стабильности и надежности которую все хотят от современной фс.
2) Рейзер явно кому-то мешал и его нечаянно так подставили, чтобы он нечаянно не сделал слишком хорошую файловую систему.Потому что в рейзер 4 почти все что вы описываете есть...или предусмотрено на будущее.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру