Cześć.

Poszukuje inspiracji a być może gotowca. Ale to trudno powiedzieć. A
chodzi o coś takiego:

Implementacja abstrkacyjnego filesystemu pracującego na urzeniau
blokowym, do którego dostęp zapewniam ja, przez stosowane abstrkacje.
Wykorzystać było by fajnie, ale najważniejsze to możliwośc podejrzenia
rozwiązań.

Wiec to tak powinno wyglądać:

struct IFooFileSystem
{
std::shared_ptr< IFile > openFile( std::string cosnt& _fileName, Flags
_flags );

bool fileExist( std::string const& _fileName );

[...]
};

struct IBlockDevice
{
std::shared_ptr< Block > readBlock( BlockIndes _index );

void writeBlock( BlockIndes _index, Block& _block );
};

struct IFile
{
void read(...);
void seek(...);
[...]
}

std::shared_ptr< IFooFileSystem >
createFileSystem( myBlockDevice );

Coś w ten deseń, czyli to ja dostaczam abstrakcje robiącą I/O na
poziomie block/cluster a kod realizuje wysokopoziomowe operacje plikowe.

To nie musi być z czymkolwiek kompatybilne, nawet lepiej gdyby nie było.
Musi być natomist komplenie nie zależne od czegokolwiek, czy to systemu
czy zewnatrznych biblitek. I thread safe, będę jednoczesnie czytał i
zapisywał wiele "plików" z róznych wątków. W zasadzie poza "plikami"
reszta kompletnie zbędna, nie interesują mnie atrybuty czy nawet
katalogi. Mocno uproszczony filesystem, coś w rodzaju wielu niezależnych
strumieni w jednym kontenerze.

Mogę to napisać samodzielnie, ale zanim to zrobie: ktoś widział taki
projekt lub część jakiegoś projektu?

Dla zastanawiajacych się po co mi to:

Jest *prawdziwy* plik. W moim kodzie jest konwertowany do urządzenia
blokowego i wystawiany do tego mechanizmu fiesystemu.

Dzięki temu mogę w jednym pliku trzymac w środku wiele plików,
bezustannie je czytajac i zmieniając. Ułatwi mi to pracę, ponieważ pliki
te są trzymane razem, user nie może nic w nich popsuć, nie muszę
bezustannie pakować/rozpakować jak robi np. OpenOffice (u nich
kontenerem jest packer). Od razu gotowe do pracy.

Katalog odpada: user może w nim coś popsuć.

Ewentualne puchnięcie moża jakoś obejśc pisząc garbage collector
trimujący ten "wirtualny filesystem" i przenoszący bloki w tle.

Coś podobnego robi np. VirtualBox ale nie chodzi o taki poziom emulacji
dysków, to ma byc mała pierdoła do kodu który mam pod kontrolą.

Innymi słowy: czy ktoś widział tego typu wirtualny filesystem?
Interesują mnie zagadnienia takie jak uproszczony wielodostęp czy
realizacja kroniki. Chciałbym je poderzeć, ponieważ nie mam w tym
doswiadczenia, pewnie napiszę to mało optymalnie.

Projekt Fuse nie nadaje się bez bardzo poważnego wrapowania. Ponadto ja
nie potrzebuje wielu filesystemów, potrzebuje tylko jeden, o mało ważnej
kompatybilności ze światem zewnętrznym. Taki FooFS.

do góry

On Thursday, January 14, 2021 at 1:31:18 PM UTC+1, heby wrote:
> Cześć.
>
> Poszukuje inspiracji a być może gotowca. Ale to trudno powiedzieć. A
> chodzi o coś takiego:
>
> Implementacja abstrkacyjnego filesystemu pracującego na urzeniau
> blokowym, do którego dostęp zapewniam ja, przez stosowane abstrkacje.
> Wykorzystać było by fajnie, ale najważniejsze to możliwośc podejrzenia
> rozwiązań.
>
> Wiec to tak powinno wyglądać:
>
> struct IFooFileSystem
> {
> std::shared_ptr< IFile > openFile( std::string cosnt& _fileName, Flags
> _flags );
>
> bool fileExist( std::string const& _fileName );
>
> [...]
> };
>
> struct IBlockDevice
> {
> std::shared_ptr< Block > readBlock( BlockIndes _index );
>
> void writeBlock( BlockIndes _index, Block& _block );
> };
>
> struct IFile
> {
> void read(...);
> void seek(...);
> [...]
> }
>
> std::shared_ptr< IFooFileSystem >
> createFileSystem( myBlockDevice );
>
> Coś w ten deseń, czyli to ja dostaczam abstrakcje robiącą I/O na
> poziomie block/cluster a kod realizuje wysokopoziomowe operacje plikowe.
>
> To nie musi być z czymkolwiek kompatybilne, nawet lepiej gdyby nie było.
> Musi być natomist komplenie nie zależne od czegokolwiek, czy to systemu
> czy zewnatrznych biblitek. I thread safe, będę jednoczesnie czytał i
> zapisywał wiele "plików" z róznych wątków. W zasadzie poza "plikami"
> reszta kompletnie zbędna, nie interesują mnie atrybuty czy nawet
> katalogi. Mocno uproszczony filesystem, coś w rodzaju wielu niezależnych
> strumieni w jednym kontenerze.
>
> Mogę to napisać samodzielnie, ale zanim to zrobie: ktoś widział taki
> projekt lub część jakiegoś projektu?
>
> Dla zastanawiajacych się po co mi to:
>
> Jest *prawdziwy* plik. W moim kodzie jest konwertowany do urządzenia
> blokowego i wystawiany do tego mechanizmu fiesystemu.
>
> Dzięki temu mogę w jednym pliku trzymac w środku wiele plików,
> bezustannie je czytajac i zmieniając. Ułatwi mi to pracę, ponieważ pliki
> te są trzymane razem, user nie może nic w nich popsuć, nie muszę
> bezustannie pakować/rozpakować jak robi np. OpenOffice (u nich
> kontenerem jest packer). Od razu gotowe do pracy.
>
> Katalog odpada: user może w nim coś popsuć.
>
> Ewentualne puchnięcie moża jakoś obejśc pisząc garbage collector
> trimujący ten "wirtualny filesystem" i przenoszący bloki w tle.
>
> Coś podobnego robi np. VirtualBox ale nie chodzi o taki poziom emulacji
> dysków, to ma byc mała pierdoła do kodu który mam pod kontrolą.
>
> Innymi słowy: czy ktoś widział tego typu wirtualny filesystem?
> Interesują mnie zagadnienia takie jak uproszczony wielodostęp czy
> realizacja kroniki. Chciałbym je poderzeć, ponieważ nie mam w tym
> doswiadczenia, pewnie napiszę to mało optymalnie.
>
> Projekt Fuse nie nadaje się bez bardzo poważnego wrapowania. Ponadto ja
> nie potrzebuje wielu filesystemów, potrzebuje tylko jeden, o mało ważnej
> kompatybilności ze światem zewnętrznym. Taki FooFS.

Jakby to miało być wydajnościowo optymalne, to by wymagało dużego nakładu pracy,
wielu prób, tunignu, testów, debugowania... W jakim sensie to by miało być optymalne?


Pozdrawiam

do góry

On 05/02/2021 19:42, M.M. wrote:
> W jakim sensie to by miało być optymalne?

Nie musi być optymalne. To tylko optymalizacja user/programista. Z
jednej strony wszystko w jednym pliku pakowanym ZIPem, z drugiej strony
milion plików w których user może coś pozmieniać i nieszczęscie gotowe.
Taki "filesystem w pliku" pozwoli kosztem niewielkiego spadu wydajności
uzyskać spójny zbiór danych w którym user grzebać nie będzie, nawet
przypadkiem.

To tak "baza danych" tylko że zamiast tabel w środku sa same bloby...
obecnie mam właśnie taką emulację, na sqlite. Ale to jest zupełnie
niepotrzebne, ponadto taki wirtualny filesystem, przy odrobinie wprawy,
pozwalałby na częsciowe mapowanie plików w pamięć, czego bloby w sql nie
potrafią.

do góry

On Sunday, February 7, 2021 at 12:55:37 PM UTC+1, heby wrote:
> On 05/02/2021 19:42, M.M. wrote:
> > W jakim sensie to by miało być optymalne?
> Nie musi być optymalne. To tylko optymalizacja user/programista. Z
> jednej strony wszystko w jednym pliku pakowanym ZIPem, z drugiej strony
> milion plików w których user może coś pozmieniać i nieszczęscie gotowe.
> Taki "filesystem w pliku" pozwoli kosztem niewielkiego spadu wydajności
> uzyskać spójny zbiór danych w którym user grzebać nie będzie, nawet
> przypadkiem.
>
> To tak "baza danych" tylko że zamiast tabel w środku sa same bloby...
> obecnie mam właśnie taką emulację, na sqlite. Ale to jest zupełnie
> niepotrzebne, ponadto taki wirtualny filesystem, przy odrobinie wprawy,
> pozwalałby na częsciowe mapowanie plików w pamięć, czego bloby w sql nie
> potrafią.

Jakbym musiał zaimplementować ręcznie bliżej nie określone rozwiązanie, to
bym zrobił listę na dysku. Nie wydaje się to szczególnie trudne.

Takich kilka chaotycznych/zgrubnych i nie do końca przemyślanych wskazówek : By
trzeba
zdefiniować rozmiar węzła, nagłówek dla wolnego węzła, nagłówek dla pustego węzła i
nagłówek pliku. W nagłówku pustego byłby adres następnego pustego - czyli lista
wolnych
węzłów. W nagłówku pliku adres pierwszego pustego węzła, jeśli by wskazywał na koniec
pliku, to nowy węzeł można utworzyć na końcu pliku przez zwiększenie rozmiaru. Za
nagłówkiem
pierwszy węzeł pliku z informacją o systemie plików, czyli nazwa pliku i pierwszy
węzeł pliku i
może jakieś dane pomocnicze, jak np. długość pliku, suma kontrolna, może nawet dane
naprawcze - to już zależne od szczegółowych wymagań. Nagłówek węzła pliku by musiał
zawierać adres następnego węzła a może także adres następnego 10tego węzła, wtedy
seek dla długich plików zadziałałoby 10 razy szybciej. Zwalnianie węzła można zrobić
przez wpis do węzła danych z na nagłówka pliku o następnym wolnym węźle, a do
nagłówka
pliku przepisujemy informację o nowym pierwszym wolnym węźle.

Aby znaleźć plik, trzeba przeszukać listę systemu plików. Nazwy plików mogą być też w
danych pliku, a w liście systemu plików tylko funkcje skrótu nazw plików, to powinno
przyspieszyć wyszukiwanie.

Odczyt pliku to odczyt danych z pierwszego węzła i skok do drugiego węzła, potem
odczyt z drugiego i znowu skok do kolejnego.

Optymalizowanie tego, dostosowywanie tego do konkretnego rozwiązania, już takie
łatwe nie jest.

Pozdrawiam

do góry

On 07/02/2021 15:34, M.M. wrote:
> Takich kilka chaotycznych/zgrubnych i nie do końca przemyślanych wskazówek : By
trzeba
> zdefiniować rozmiar węzła,

Dzięki za pomysły. Tak naprawdę najbardziej mnie interesują dwie rzeczy:
1) jak realizuje sie kronikowanie - tak bardziej pod kątem teoretycznym

2) jak realizuej się wielodostep z wątków i locki w systemie.

> Optymalizowanie tego, dostosowywanie tego do konkretnego rozwiązania, już takie
> łatwe nie jest.

Na razie poszukuje inspiracji aby ocenić czy to w ogóle ma sens.
Wyskrobać sam coś może i wyskrobię, ale głupio robić na starcie szkolne
błędy.

do góry

On Sunday, February 7, 2021 at 7:04:31 PM UTC+1, heby wrote:
> On 07/02/2021 15:34, M.M. wrote:
> > Takich kilka chaotycznych/zgrubnych i nie do końca przemyślanych wskazówek : By
trzeba
> > zdefiniować rozmiar węzła,
> Dzięki za pomysły. Tak naprawdę najbardziej mnie interesują dwie rzeczy:
> 1) jak realizuje sie kronikowanie - tak bardziej pod kątem teoretycznym
>
> 2) jak realizuej się wielodostep z wątków i locki w systemie.
> > Optymalizowanie tego, dostosowywanie tego do konkretnego rozwiązania, już takie
> > łatwe nie jest.
> Na razie poszukuje inspiracji aby ocenić czy to w ogóle ma sens.
> Wyskrobać sam coś może i wyskrobię, ale głupio robić na starcie szkolne
> błędy.

do góry

On Sunday, February 7, 2021 at 7:04:31 PM UTC+1, heby wrote:
> On 07/02/2021 15:34, M.M. wrote:
> > Takich kilka chaotycznych/zgrubnych i nie do końca przemyślanych wskazówek : By
trzeba
> > zdefiniować rozmiar węzła,
> Dzięki za pomysły. Tak naprawdę najbardziej mnie interesują dwie rzeczy:
> 1) jak realizuje sie kronikowanie - tak bardziej pod kątem teoretycznym

W najbardziej podstawowej wersji kronikowanie to rejestr operacji, w przeciwieństwie
do
pliku który jest efektem (tychże operacji). Jeśli mamy cały rejestr operacji, to
możemy z
nich odtworzyć cały plik. Plik jest potrzebny tylko ze względów wydajnościowych. Sens
kronikowania jest tylko w połączeniu z transakcjami. Muszą wszystkie operacje z
transakcji
trafić do plików, albo żadna. W wielkim skrócie jest utrzymywana kopia do naprawy gdy
nie uda się zamknąć transakcji, albo gdy się uda, ale zasilanie padnie w trakcie
przerzucania z
dziennika do zbiorów danych.

> 2) jak realizuej się wielodostep z wątków i locki w systemie.

Z ciekawości zapytam, do czego potrzebujesz takiej wiedzy?


> > Optymalizowanie tego, dostosowywanie tego do konkretnego rozwiązania, już takie
> > łatwe nie jest.

> Na razie poszukuje inspiracji aby ocenić czy to w ogóle ma sens.
Ale co ma sens? Pakowanie danych jakiejś aplikacji do jednego pliku - myślę
że ma sens, wygląda to bardziej elegancko niż do jednego katalogu. Czy
jest sens pisania tego samemu od zera? Nie wiem, zależy jakie są gotowe
rozwiązania, nie potrafię polecić żadnego gotowca. Pisanie do jednego
katalogu, a potem zip katalogu - też nie głupie, a nakład pracy mały, bo
zip jest darmowy i dokument będzie od razu skompresowany.

Natomiast co może mieć sens w kontekście wątków i ich realizacji w
systemach operacyjnych - to nawet się nie domyślam.


> Wyskrobać sam coś może i wyskrobię, ale głupio robić na starcie szkolne
> błędy.

To chyba nieuniknione w przypadku ciut większych projektów - chyba że
coś bardzo podobnego robimy po raz któryś.

Pozdrawiam

do góry

On 07/02/2021 20:03, M.M. wrote:
>> 2) jak realizuej się wielodostep z wątków i locki w systemie.
> Z ciekawości zapytam, do czego potrzebujesz takiej wiedzy?

Nie chcę 1 mutexa na wszystko. Wątków dostepowych będzie wiele. Skoro fs
są używane praktycznie wyłącznie w środowiskach wielowątkowych, to
przypuszczam że nie jest to jakaś specjalnie trudna sprawa. Znowu: mam
jakieś pomysły, ale pewnie naiwne.

Ba, zerknąłem w kod kilku fs, ale ciezko znaleźc jakieś anstrakcje,
zazwyczaj się silnie zoptymalizowane i struktura traci sie w
optymalizacjach.

>> Na razie poszukuje inspiracji aby ocenić czy to w ogóle ma sens.
> Ale co ma sens? Pakowanie danych jakiejś aplikacji do jednego pliku - myślę
> że ma sens, wygląda to bardziej elegancko niż do jednego katalogu. Czy
> jest sens pisania tego samemu od zera? Nie wiem, zależy jakie są gotowe
> rozwiązania, nie potrafię polecić żadnego gotowca.

Wolałbym gotowiec właśnie. W zasadzie to wolałbym tego w ogóle nie
pisać, tylko skupić się na pozostałem częsci apliakcji.

Tak naprawdę, tam jest kilka innych zagadnień, których gotowce
prawodpodobnie nie rozwiązują: np. defragmentacja w tle i powiązany z
nim trim prawdziwego pliku.

do góry

On Sunday, February 7, 2021 at 8:57:46 PM UTC+1, heby wrote:
> On 07/02/2021 20:03, M.M. wrote:
> >> 2) jak realizuej się wielodostep z wątków i locki w systemie.
> > Z ciekawości zapytam, do czego potrzebujesz takiej wiedzy?
> Nie chcę 1 mutexa na wszystko. Wątków dostepowych będzie wiele. Skoro fs
> są używane praktycznie wyłącznie w środowiskach wielowątkowych, to
> przypuszczam że nie jest to jakaś specjalnie trudna sprawa. Znowu: mam
> jakieś pomysły, ale pewnie naiwne.

Nie pytałem ile chcesz mutexów. Nie wiem do czego tej wiedzy potrzebujesz. Jak tej
wiedzy potrzebujesz do zaprojektowania procesora - to ja nie pomogę. Mutex
koncepcyjnie to prosta sprawa, jest gwarancja wykonania fragmentu kodu tak,
jakby wykonywał go jeden wątek. Cechą specyficzna tego kodu jest zazwyczaj
zliczanie ile wątków przeszło przez jakąś barierę. Ale jaką techniką trzeba napylić
tranzystory aby to działało optymalnie - nie mam bladego pojęcia.


> Ba, zerknąłem w kod kilku fs, ale ciezko znaleźc jakieś anstrakcje,
> zazwyczaj się silnie zoptymalizowane i struktura traci sie w
> optymalizacjach.

Uroki optymalizacji... coś za coś.

> >> Na razie poszukuje inspiracji aby ocenić czy to w ogóle ma sens.
> > Ale co ma sens? Pakowanie danych jakiejś aplikacji do jednego pliku - myślę
> > że ma sens, wygląda to bardziej elegancko niż do jednego katalogu. Czy
> > jest sens pisania tego samemu od zera? Nie wiem, zależy jakie są gotowe
> > rozwiązania, nie potrafię polecić żadnego gotowca.
> Wolałbym gotowiec właśnie. W zasadzie to wolałbym tego w ogóle nie
> pisać, tylko skupić się na pozostałem częsci apliakcji.

> Tak naprawdę, tam jest kilka innych zagadnień, których gotowce
> prawodpodobnie nie rozwiązują: np. defragmentacja w tle i powiązany z
> nim trim prawdziwego pliku.

Jeśli dysponujemy dodatkowym miejsce to defragmentuje się łatwo: odczytuje
się kolejne pliki z jednego systemu i zapisuje do drugiego. Czasami warto
zostawić trochę miejsca za plikiem do dopisania nowych danych... Bez konkretnego
zastosowania trudno gdybać.

Pozdrawiam

do góry

On 07/02/2021 21:19, M.M. wrote:
> Nie pytałem ile chcesz mutexów. Nie wiem do czego tej wiedzy potrzebujesz. Jak tej
> wiedzy potrzebujesz do zaprojektowania procesora - to ja nie pomogę.

Nie projektuje procesora.

> Mutex
> koncepcyjnie to prosta sprawa

Tu mutex powinien być na "fragment" filesystemu. Jestem prawie pewny, że
w normalnym fs takie "mutexy" są powiązane z kroniką co czyni jest
bardziej mechanizmem transakcyjnym niż prostym lockiem.

> zliczanie ile wątków przeszło przez jakąś barierę. Ale jaką techniką trzeba napylić
> tranzystory

No wiec nie napylam tanzystorów.

>> Tak naprawdę, tam jest kilka innych zagadnień, których gotowce
>> prawodpodobnie nie rozwiązują: np. defragmentacja w tle i powiązany z
>> nim trim prawdziwego pliku.
> Jeśli dysponujemy dodatkowym miejsce to defragmentuje się łatwo: odczytuje
> się kolejne pliki z jednego systemu i zapisuje do drugiego.

To jest naiwny algorytm. Wszystkie fs majace defragmentacje - robią ją w
miejscu. Moe to zaprojektowc metodą garbage collectora z javy: stop the
world. Ale coś czuje że to znowu naiwny algorytm.

do góry