Sunday, March 15, 2009

Co mnie wkurza w systemie plików

Witam,
Dzisiaj chciałbym napisać, co mi nie odpowiada w popularnych systemach plików - mam tutaj na myśli te, z którymi się na co dzień spotykam (windows, solaris, linux - przeważnie fat,ntfs,ext2/3,reiserfs). Z tego co się orientuję, to ograniczenie leży po stronie systemu, a raczej logiki systemu plików.

Otóż chciałbym stworzyć jakąś aplikację - kod źródłowy miałby leżeć w /src. Plik główny miałby się nazywać main.src. Ale kod miałby się odwoływać do deklaracji a implementacje byłyby położone w main.src/implementacja.src.
Otóż popełniam w mojej logice 2 poważne błędy:
1) Nazwa pliku... czym ona jest?
2) Jeśli mówimy, że coś jest w jakimś większym kontenerze to jest to plik w katalogu.

Moim zdaniem dostęp logiczny do obiektu odbywający się po jego nazwie jest błędny (dobrym rozwiązaniem jest HTML, gdzie obiekty mają swoją nieunikalną nazwę i unikalny ID). To jest błąd leżący w założeniach tego, jak wyglądają systemy plików.

Błędem jest również założenie, że mogę mieć plik i katalog o tej samej nazwie - tego zrobić nie mogę. Dostęp odbywa się po nazwie (nie po ID) więc otwierając c:\windows otwieram.... no właśnie... obiekt o nazwie c:\windows.

Jak ja to widzę...
System plików powinien się składać z fizycznych "grup danych" zawierających wiele jednostek logicznych powiązanych ze sobą w jakiś użyteczny sposób. Wewnątrz takiej grupy powinny istnieć obiekty logiczne posiadające własne unikalne identyfikatory (unikalność powinna być zapewniona w obrębie jednego systemu plików, t.j. w obrębie partycji logicznej, lub też w obrębie grupy danych). Niezależnie od tego powinna istnieć struktura logiczna opisująca nasze obiekty logiczne. Powinna zawierać grupy obiektów określając je po ich identyfikatorach. Problem: Jak identyfikować grupy obiektów? Najlepiej chyba aby miały formę "tagów" przypisywanych do obiektów logicznych (tyle, że atrybut nie byłby przypisany do pliku ale plik do atrybutu).
Problem: Oznaczałoby to zupełnie nowe podejście do plików - odwołanie do kontenera danych odbywałoby się poprzez podanie unikalnego identyfikatora systemu plików(obiektów?)+identyfikatora obiektu (który jest unikalny w obrębie systemu plików). Alternatywnie możnaby się odwoływać do jakiejś grupy obiektów w celu otrzymania ich listy.
Do tego dorzućmy ochronę - system un*xowy się sprawdził - więc można tego użyć.

Zaleta: Możnaby tworzyć kilka obiektów o tych samych nazwach.
Wada: Duża ilość grup.
Wada: Nazwa obiektu musiałaby być gdzieś osobno trzymana.
Wada: Nie wspomniałem o fizycznych danych - to byłaby oddzielna warstwa.

Podsumowując:
Widzę system danych jako 3 warstwy: warstwa fizyczna (zbliżona do obecnej), warstwa logiczna trzymająca dane oraz warstwa logiczna opisująca dane.

Warstwa fizyczna:
Bloki, cylindry, sektory, itd. pogrupowane w większe grupy fizyczne. Grupowanie możnaby np. wykonać względem szybkości dostępu do danych i ryzyka utraty danych. Odwołanie do danych może się odbywać poprzez podanie ID grupy+numeru jednostki alokacji.

Warstwa logiczna odpowiedzialna za trzymanie danych:
Zależna od warstwy fizycznej.
Każdy obiekt logiczny posiada rodzica. Każdy obiekt logiczny może posiadać dzieci. Tak oto załatwiliśmy strawę kontenerów obiektów (katalogów/folderów).
Każdy obiekt posiada właściciela.
Każdy obiekt posiada opis uprawnień dla właściciela (niech to będzie x bitów).
Możnaby jeszcze dodać standardowe atrybuty trzymane w tej warstwie - chociaż to już jest ryzykowne.

Warstwa logiczna opisu danych:
Zawiera grupy z ich nazwami, właścicielami oraz uprawnieniami (x bitów). Właściciel powinien tutaj stanowić grupę użytkowników.
Zawiera listę ID obiektów logicznych powiązanych z daną grupą.
Tagi możnaby podzielić na konfigurowalne przez użytkownika oraz przypisane na stałe do obiektów (to już niestety odejście od standardowego podejścia do plików).

Potencjalne problemy:
Dane dzielone między 2 i więcej bloki logiczne/fizyczne.

Przykładowy dostęp do plików gry XYZ:
Pobierz pliki posiadające tag XYZ => lista ID.
Pobierz pliki posiadające tag 'grafika' pomiędzy otrzymanymi ID.
Pobierz zależności rodzic/dziecko obiektów i pobierz dalej dane jak w standardowo używanych systemach plików.

Przykładowe wyszukanie dokumentów przez użytkownika:
Wyszukaj pliki które są moje i które zostały ściągnięte aplikacją "przeglądarka".
Dodatkowo szukaj plików o jakiejś nazwie.

Jeśli ktoś przypadkiem to czyta to jestem ciekaw czy będą do tej wizji jakieś uwagi :)