>>>При параллельном доступе? Да не вопрос, только машин станет в 2 раза
>>>больше... (или насколько там udmu медленее).
>>
>>не на сколько, 6 из 18 use cases медленнее на 15% (или
>>меньше - лень в документы смотреть). В остальных быстрее.
>>А с уходом от глупого vfs в линухе (для ost) - будет
>>значительно быстрее.
>
>:) не совсем так, при бОльших массивах слив в разы.

да ну? у вас сведения более точные чем внутренние тесты Sun?

>[оверквотинг удален]
>>
>>найдите в себе мужество разобраться - что такое DMU, что такое zfs-fusе!
>>
>>DMU это сторадж с транзакциями. Самый ближайший аналог inodefs в FreeBSD.
>>собственноо это основное что делали патчи в ldiskfs, сделать сторадж с транзакциями
>>для обхода работы с именами и иметь возможность цеплять свои callback
>>на конец транзакций и тп.
>
>Ога, а теперь посмотрим, может ли это предоставить zfs-fuse (после напильника, хотя
>может уже и есть)...

вы специально говорите глупость или не берете на себя труд разобраться?
возьмите листок бумаги.. нарисуйте структуру FS по уровням.
начиная с аллокации блоков, и заканчивая директориями/файлами поверх стораджа.
zfs (хоть zfs-fuse) это самый высокий уровень, люстре столько не надо.
ей нужны более низко уровеневые веши - уровень стораджа с транзакциями.
можно понять что это 2 паралельных ветки - dmu + some directroy structure => zfs и модуль для работы с готовой zfs через fuse-api, fuse-zfs.
и вторая ветка dmu+OSS/MDS (uOSS/uMDS) - которая используется для lustre.

мне честно - страшно что человек с такими знаниями берется писать файловую систему...