Изпечатай

[gat3way]

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

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

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

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

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

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

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

[tarator]

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

[gat3way]

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

[Йордан]

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

[gat3way]

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

[tarator]

Такаа, първо да спомена, че 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. Ако е бавна, мери и мисли как да забързаш бавните части.

[gat3way]

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

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

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

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

[tarator]

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

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

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

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

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

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

[Йордан]

Цитат (gat3way @ Ян. 01 2008,20:45)

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

Все същото е. Всичко зависи от случая, от това за какво ще го ползваш ;-)

Едва ли би искал файловата ти система, която държи на раменете си масив от няколко терабайта да е fuse? Или gmailfs да ти се бута по ядрото?

[gat3way]

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

[tarator]

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

И защо не?

[gat3way]

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

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

[Йордан]

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

[tarator]

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

[gat3way]

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