Linux за българи: Форуми

Айде да видим сега големите философи и експерти колко ще си чешат езиците и какви ще ги творят. Въпросът е забавен.

Кое мислите, че е по-удачен вариант за реализиране на файлова система? FUSE (userspace-базирана) или такава, базирана върху VFS слоя на ядрото?

Принципно ядрото е писано на С, а моделът на файловите системи по подразбиране се описва много по-добре с обектно-ориентирани езици Това до известна степен доста ограничава реализацията на някакви новаторски проекти в областта.

От друга страна, реализирането на файлова система под формата на потребителски процеси, комуникиращи с ядрото е бавно, има много context switching, разчита се на работещи като хората такива процеси, изнасянето на тази функционалност извън ring0 предразполага към проблеми със сигурността. Въпреки всичко, някои ОС-и (обикновенно такива с микроядра) правят точно така.

Проблем с block layer-a отдолу обикновено води до лоши последици, когато файловата система се реализира в ядрото. smbfs (въпреки че не е добър пример) е доволно добра илюстрация за което.

С FUSE-базирани файлови системи, стабилността на системата не го отнася при такива обстоятелства.

Какво мислите

Сега нямам време да пиша пространно, но има операционни системи в които _всички_ файлови системи са user space. Бавно е относително понятие.

Да, тези с микроядра. Но там нещата стоят по доста различен начин.

Все едно да питаш в секса дали е по-добре да си отгоре или отдолу :-D

Мнеее, никой не е примрял да е отгоре. За различни неща говорим

Такаа, първо да спомена, че IMNSHO FUSE is piece of ####. Разбира се, като фен на Plan9, съм донякъде пристрастен, но последния път като гледах сорса й, изобщо не бях очарован. Използвай v9fs

Второ, да пусна два цитата от умни хора. Първият е от дядо Кнут:

Premature optimization is the root of all evil

И втория от дядо Фред Брукс:

Plan to throw one away. You will do that, anyway. Your only choice is whether to try to sell the throwaway to customers.

Като се погледат малко двата цитата, човек може да стигне до следния извод (сигурен съм, че някой го е казал, но не знам кой): Никога не предполагай къде ще са бавните места в програмата и не прави дизайна за да ги избегнеш. Седем пъти мери, и тогава реши

Та предположението, че context switching-a ще забави значително файловата система може да се окаже невярно: a) Повечето файлови системи са I/O bound, и б) ако си спомням правилно context switching-a е около 100-ина цикъла.

Друга причина за забавяне може да е твърде многото memcpy-та. При правилен дизайн, обаче, те могат да се избегнат.

Проблеми със сигурността не виждам. Ако не вярваш на операционната система да поддържа необходимата сигурност на процесите, не виждам защо трябва да й вярваш да го прави в kernel space.

Най-хубавия трик, който е трудно да се реализира в user space, използването на неизползваните в момента страници от паметта за кеш. Имам някакви идеи как може да се реализира в user space, но трябва да поекспериментирам

Та, според мен опитай първо с файлова система в user space. Ако е бавна, мери и мисли как да забързаш бавните части.

Това, че са I/O bound няма да промени факта, че имаш като бонус  поне още един context switch за всяка I/O операция и при положение че много процеси се бият за разни ресурси от файловата система, CPU load-a ще скочи несъмнено повече от това, което щеше да бъде, ако файловата система не беше реализирана по този начин

Друго, което съществува като проблем са точно операциите по прехвърляне на памет. Ще имаш по една бонус операция от сорта на copy_from_user() + copy_to_user() за всяка I/O операция, защото работиш в защитен режим и процесите няма как директно да си споделят някакво адресно пространство. Предполагам може да се измисли някаква схема, но звучи извратено.

Това с кеширането няма да е толкова сложно за реализиране иначе. Минават ми разни идеи за собствено заделяне на памет за разни pages и пазене на LRU структура от данни за тези страници в рамките на процесът-файлова система. Всички тези страници се намират в област, която предварително е заделена и mlock()-ната. Последното, за да не влезнат без да искат в swap-а. И съответно някой трябва да се грижи най-малко  използваните страници да си заминават както си му е реда, за да влизат нови.

Обаче всичко това е на теория.

> CPU load-a ще скочи несъмнено повече от това

Фактът, че CPU load-a е по-висок, не значи непременно, че софтуера ще работи по-бавно.

> Предполагам може да се измисли някаква схема, но звучи извратено.

Може да се измисли, и не е чак толкова извратено. Може да има някои проблеми със security.

> Минават ми разни идеи за собствено заделяне на памет за разни pages
> и пазене на LRU структура от данни за тези страници в рамките на
> процесът-файлова система.

Проблемът е как приложението да използва памет, без да я заделя екплицитно, така че ядрото да може да я даде на друг процес ако му трябва.

Нищо не се бута по ядрото (освен fuse модула, който експорт-ва syscalls, използвани от юзърспейската библиотека). По принцип това е идеята, де.  Но да, не бих държал на такава файлова система терабайти данни.

> Но да, не бих държал на такава файлова система терабайти данни.

И защо не?

Нямам доверие на автора на такова нещо Утре ще се откаже, ще сменят леко API-то на libfuse и след някой ъпдейт ще се изненадам много неприятно

Примерно де..

Още едно място за развъждане на бъгове

Да, те щото изобщо не сменят API-то на VFS в ядрото.

Промени ли се VFS layer-a, със сигурност се променя и FUSE хехе

> Промени ли се VFS layer-a, със сигурност се променя и FUSE хехе

Затова използвай 9P

Хехехе

Аз съм по скоро за хибридна реализация от типа на drivers in userspace които реално са някакъв микромизерен модул за ядрото и userspace част + инструменти.

Защо?

Между другото, fuse много наподобява на това, за което говориш.

реално по този начин си осигуряваш апи ...

мда всъщност това е FUSE

трябва да се старая сутрин да мисля повечки

Ей и v9 било забавно нещо. fuse не бих определил защо е станал толкова комерсиален като идея. Много забавно било това с userspace файловите системи, интересни идеи хрумват. Някой има ли идея къде мога да намеря сравнителни тестове между другото? Гледах едни графики, които според мен са измислени доволно, през LWN...

Графики за какво?

Най-големия проблем на v9fs е че няма добра документация как да се пишат файлови системи за нея. Един колега, който иска да я използва за някакъв AirForce проект се оплакваше преди няколко дни. Май трябва да взема да напиша някоя статия по въпроса в  Linux Journal или Linux Magazine...

Иначе ако измислиш нещо хитро и решиш да го пишеш с npfs/spfs и имаш въпроси, питай

Хмм, какво стана, че моят отговор се появи преди въпроса?

Като сте отворили темата, какво мислите за [GlusterFS].
Имаше лекция по тази тема на последния Openfest. [видео]
[Тук]  има малко тестове.

Начи мисля , че най-важното е за какво ще се ползва тая файлова система .Тогава може да се направи някакви сметки , коя , как и защо.
Ако е за бързина , от rootfs и tmpfs едва ли може да се постигне нещо , дори и близко до тях. Та не мисля , че юзерспейс има шанс.
Е , нямам претенции да съм прав.Не съм гледал скоро проекта FUSE  и сие  де , има ли нещо ново ?

Аз май размислих:
Ако например тая файлова система е за флашка , то бързината си е абсолютно без значение , и юзерспейс си е 100% по доброто.
Като друго предимство , имаш библиотека , без която и дявола няма да може да разчете какво е на флашката , а и много по лесно ще е за писане , и съобразено с особенностите на носитела.

Maniac,

Един приятел, който знае доста за паралелни файлови системи (участвал е в разработката на Intermezzo едно време), не беше чувал за GlusterFS Обеща да я погледне. Ако не ме домързи може да я инсталирам на някой от тестовите ни клъстъри и да я пробвам.

romeo_ninov,

Всички (сериозни) паралелни файлови системи разделят метаинформацията от данните. Данните се разпаралеляват много по-лесно отколкото метаинформацията.

Обикновено паралелните файлови системи не се интересуват толкова от failure, колкото от scalability. Поне в HPC, където знам повече. Става въпрос за системи като Lustre, Panasas, pNFS, PVFS и т.н.

> There is no meta data info or meta data server in GlusterFS. It is
> handled by the underlying file system. Also there is nothing central in
> GlusterFS. It is truly distributed and no single point of failure.

Bullshit. Като гледам няма нито една статия написана за GlusterFS. Започвам да подозирам, че не струва.