On Sunday, February 7, 2021 at 10:01:21 PM UTC+1, heby wrote:
> 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.

To dlaczego nie odpowiesz na pytanie: do czego potrzebujesz wiedzę o takich
szczegółach synchronizacji wątków?

>
> > Mutex
> > koncepcyjnie to prosta sprawa
>
> Tu mutex powinien być na "fragment" filesystemu.

Tu czyli gdzie i dlaczego na fragment filesystemu? Co rozumiesz przez filesystem?

>Jestem prawie pewny, że
> w normalnym fs takie "mutexy" są powiązane z kroniką co czyni jest
> bardziej mechanizmem transakcyjnym niż prostym lockiem.

Transakcje nie są prostym lockiem, aczkolwiek z poziomu użytkownika to proste
wywołanie funkcji, np. w bazie danych komenda "begin" rozpoczyna transakcje.
Transakcje umożliwiają naprawę tego co 'zaczęło' być modyfikowane.


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

Dlaczego więc chcesz wiedzieć jak wewnętrznie działają mutexy?


> >> 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.
Naiwne algorytmy mają swoje zalety.

> 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.

GC zlicza odnośniki do alokowanych obiektów, gdy jest zero, to może zwolnić.
Jaka jest optymalna struktura do takiego zliczania? Może jakieś drzewo
zbalansowane i kolejka priorytetowa, a może naiwna liniowa tablica ma tak
mały narzut że to właśnie ją się najbardziej opłaca stosować dla typowych
aplikacji - nie wiem.

Pozdrawiam

do góry

On 07/02/2021 22:53, M.M. wrote:
> To dlaczego nie odpowiesz na pytanie: do czego potrzebujesz wiedzę o takich
> szczegółach synchronizacji wątków?

Ponieważ mutex w pamięci, dostarczany przez OS niekoniecznie jest tym
samym co "mutex" na plik (lock) zapewniajacy spójnośc dnych podczas
wielodostępu i defragmentacji w tle. Wymaga ręcznej implementacji, być
moze opartej o mutexy OSowe, a może niekoniecznie, a może w ogóle są
rozwiązania bez mutexa.

>>> koncepcyjnie to prosta sprawa
>> Tu mutex powinien być na "fragment" filesystemu.
> Tu czyli gdzie i dlaczego na fragment filesystemu? Co rozumiesz przez filesystem?

Na przykład na wirtualny plik w tym kontenerze.

Wyobraź sobie dwa wątki: jeden dopisuje coś do wirtualnego pliku, a
drugi kasuje go.

Można to rozwiązać za pomocą inodes, jak w linuxie. Albo za pomocą
mutexów "w filesystemie".

Oczywiście te "mutexy w filesystemie" to naiwny koncept. To mogą być
zwykłe mutexy w implementacji filesystemu, ale raczej nie będą.

> Transakcje nie są prostym lockiem

Bo transakcja to kiepskie słowo. W zasadzie nie ma dobrego odpowiednika
w DB zachowania filesystemu z kronikowaniem zapisywanego przez wiele wątków.

>>> zliczanie ile wątków przeszło przez jakąś barierę. Ale jaką techniką trzeba
napylić
>>> tranzystory
>> No wiec nie napylam tanzystorów.
> Dlaczego więc chcesz wiedzieć jak wewnętrznie działają mutexy?

Nigdzie nie napisałem że chce wiedzieć jak działają *normalne* mutexy,
bo to wiem. Interesuje mnie jak działa zapewnianie spójności danych w fs
które dla usera wygląda jak typowy zasób krytyczny pilnowany przez mutex.

>> 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.
> GC zlicza odnośniki do alokowanych obiektów, gdy jest zero, to może zwolnić.

Wiem, ale GC nie pojawił sie tutaj jako odpowiednik 1:1 tylko jao zły
przykład "stop the world".

> Jaka jest optymalna struktura do takiego zliczania? Może jakieś drzewo
> zbalansowane i kolejka priorytetowa, a może naiwna liniowa tablica ma tak
> mały narzut że to właśnie ją się najbardziej opłaca stosować dla typowych
> aplikacji - nie wiem.

Potrzebuje literatury z teorii działania systemów plików. Wygdybać mogę
sobie cokolwiek, ale konkuruje z dziesięcioleciami eksperymentów ludzi
mądrzejszych ode mnie.

do góry

On Monday, February 8, 2021 at 7:39:33 AM UTC+1, heby wrote:
> On 07/02/2021 22:53, M.M. wrote:
> > To dlaczego nie odpowiesz na pytanie: do czego potrzebujesz wiedzę o takich
> > szczegółach synchronizacji wątków?

> Ponieważ mutex w pamięci, dostarczany przez OS niekoniecznie jest tym
> samym co "mutex" na plik (lock) zapewniajacy spójnośc dnych podczas
> wielodostępu i defragmentacji w tle. Wymaga ręcznej implementacji, być
> moze opartej o mutexy OSowe, a może niekoniecznie, a może w ogóle są
> rozwiązania bez mutexa.

Dane na których program pracuje to są dane, nie ma istotnego znaczenia
czy są one zapisane w pamięci RAM, na dysku talerzowym, na dysku SSD,
na płycie CD, DVD, itd. Podobnie dane naprawcze to dane naprawcze, jeśli
są poprawne, to można dzieki nimi coś naprawić bez względu gdzie są
zapisane. Jedyna istotna różnica jest taka, że jak padnie system, to
też dochodzi do utraty danych w pamięci RAM i nie ma w niej nic do
naprawiania. Dlatego w przypadku danych na pamięciach trwałych stosuje
się nie tylko mutexy, ale jeszcze przechowuje się dane naprawcze, które
(z tego co wiem zawsze) są w dzienniku zawierającym informacje o
modyfikacjach.

Mutex sam w sobie nic nie zapewnia, spójność danych uzyskuje się
dzięki prawidłowmu użyciu mutexów i danych naprawczych.


> >>> koncepcyjnie to prosta sprawa
> >> Tu mutex powinien być na "fragment" filesystemu.
> > Tu czyli gdzie i dlaczego na fragment filesystemu? Co rozumiesz przez filesystem?
> Na przykład na wirtualny plik w tym kontenerze.
>
> Wyobraź sobie dwa wątki: jeden dopisuje coś do wirtualnego pliku, a
> drugi kasuje go.

To jeszcze nic nie oznacza, może programista tak chciał? Ale generalnie
na tym właśnie polega problem: kilka wątków pracuje na tych samych
danych, zakładają że dane mają określoną wartość. Gdy jeden wątek dane
zmodyfikuje, to pozostałe już pracują na błędnym założeniu. Dlatego
robi się to co napisałem: jeśli jeden wątek zapisuje dane, to może
pracować tylko ten jeden wątek, ale do odczytu może być dowolnie wiele.


> Można to rozwiązać za pomocą inodes, jak w linuxie. Albo za pomocą
> mutexów "w filesystemie".
>
> Oczywiście te "mutexy w filesystemie" to naiwny koncept. To mogą być
> zwykłe mutexy w implementacji filesystemu, ale raczej nie będą.
>
> > Transakcje nie są prostym lockiem
>
> Bo transakcja to kiepskie słowo. W zasadzie nie ma dobrego odpowiednika
> w DB zachowania filesystemu z kronikowaniem zapisywanego przez wiele wątków.

Też nie spotkałem się.


> >>> zliczanie ile wątków przeszło przez jakąś barierę. Ale jaką techniką trzeba
napylić
> >>> tranzystory
> >> No wiec nie napylam tanzystorów.
> > Dlaczego więc chcesz wiedzieć jak wewnętrznie działają mutexy?
> Nigdzie nie napisałem że chce wiedzieć jak działają *normalne* mutexy,
> bo to wiem. Interesuje mnie jak działa zapewnianie spójności danych w fs
> które dla usera wygląda jak typowy zasób krytyczny pilnowany przez mutex.

Ale kto powiedział że jest takie zapewnienie? Jeśli dwa wątki zaczną
czytać i pisać dane, to zepsują spójność danych w pliku, chyba że OS
nie pozwoli otworzyć pliku do zapisu gdy jest może to spowodować
utratę spójnośći. OS powinien zapewniać tylko spójność struktury
przechowującej dane na dysku, a robi sie to tak samo jak zawsze: mutexy
i/albo dane naprawcze.


> >> 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.
> > GC zlicza odnośniki do alokowanych obiektów, gdy jest zero, to może zwolnić.

> Wiem, ale GC nie pojawił sie tutaj jako odpowiednik 1:1 tylko jao zły
> przykład "stop the world".

Ok.

> > Jaka jest optymalna struktura do takiego zliczania? Może jakieś drzewo
> > zbalansowane i kolejka priorytetowa, a może naiwna liniowa tablica ma tak
> > mały narzut że to właśnie ją się najbardziej opłaca stosować dla typowych
> > aplikacji - nie wiem.


> Potrzebuje literatury z teorii działania systemów plików. Wygdybać mogę
> sobie cokolwiek, ale konkuruje z dziesięcioleciami eksperymentów ludzi
> mądrzejszych ode mnie.

Może jest coś wartościowego?
https://www.google.com/search?channel=fs&client=ubun
tu&q=systemy+plik%C3%B3w+literatura

Pozdrawiam

do góry

On 08/02/2021 11:08, M.M. wrote:
>> Wyobraź sobie dwa wątki: jeden dopisuje coś do wirtualnego pliku, a
>> drugi kasuje go.
> To jeszcze nic nie oznacza, może programista tak chciał?

To dopuszczalna sytuacja. fs ma być na nia gotowy.

> Ale generalnie
> na tym właśnie polega problem: kilka wątków pracuje na tych samych
> danych, zakładają że dane mają określoną wartość. Gdy jeden wątek dane
> zmodyfikuje, to pozostałe już pracują na błędnym założeniu. Dlatego
> robi się to co napisałem: jeśli jeden wątek zapisuje dane, to może
> pracować tylko ten jeden wątek, ale do odczytu może być dowolnie wiele.

Nieprawda. Jeśli jeden watek zapisuje jakas częśc pliku, inny może
zapisuwać inną część tego samego pliku. DB często tak robią.

Granulacja jest więc dokładniejsza niż 1 plik. Co oznacza w naiwnym
podejściu bardzo dużo muteksów na każdy kawałek pliku lub skomplikowany
mutex z emulacją submutexów.

Przypuszcam że w ogóle sytuacja że zapisujemy ten sam kawałek pliku
równolegle z dwóch wątków jest jak najbardziej dopuszczalna. Co najwyżej
będzie race condition na dane, ale sam plik będzie dalej poprawny z
punktu widzenia fs.

>> bo to wiem. Interesuje mnie jak działa zapewnianie spójności danych w fs
>> które dla usera wygląda jak typowy zasób krytyczny pilnowany przez mutex.
> Ale kto powiedział że jest takie zapewnienie?

W fs jest. Wątek A kasuje plik, wątek B czyta ten sam plik, wątek C
właśnie go otwiera. I nie ma race conditions na poziomie fs, tam dane są
spójne i stan jest atomowy.

> Jeśli dwa wątki zaczną
> czytać i pisać dane, to zepsują spójność danych w pliku, chyba że OS
> nie pozwoli otworzyć pliku do zapisu gdy jest może to spowodować
> utratę spójnośći.

To tak nie działa. POnadto rozróznijmy: race condition w aplikacji to
coś innego niż race condition w fs. W tym drugim przypadku masz taką
sytuację setki razy na sekundę w swoim PC.

>> Potrzebuje literatury z teorii działania systemów plików. Wygdybać mogę
>> sobie cokolwiek, ale konkuruje z dziesięcioleciami eksperymentów ludzi
>> mądrzejszych ode mnie.
> Może jest coś wartościowego?
> https://www.google.com/search?channel=fs&client=ubun
tu&q=systemy+plik%C3%B3w+literatura

Obawiam się czy aby nie jest tylko od strony użytkowej. Ogólnie
obejrzałem spisy kilkunastu książek z tego tematu i jak na razie nie
widzę nic o budowie wewnętrznej. Być może coś przeoczyłem.

do góry

On Monday, February 8, 2021 at 12:12:29 PM UTC+1, heby wrote:
> On 08/02/2021 11:08, M.M. wrote:
> >> Wyobraź sobie dwa wątki: jeden dopisuje coś do wirtualnego pliku, a
> >> drugi kasuje go.
> > To jeszcze nic nie oznacza, może programista tak chciał?
> To dopuszczalna sytuacja. fs ma być na nia gotowy.

Trudno sie rozmawia, nie wiem co dla Ciebie znaczy że FS
ma być gotowy. Skąd FS ma wiedzieć, czy to nie jest zaplanowane
działanie programisty? Pracują np. dwa wątki. Jeden pisze do
pliku, drugi kasuje plik. Jeśli jeden najpierw zapisze, a drugi
skasuje - to pliku nie będzie. Jeśli najpierw skasuje, a
potem dojdzie do próby zapisania, to też nie będzie pliku - fs
zwróci po prostu błąd zapisu. Niezbyt eleganckie rozwiązanie
ale zawsze zakończy się takim samym efektem. Chyba że gotowość
dla Ciebie oznacza to, że w takiej sytuacji całkowicie się
nie rozwali i nie dojdzie do utraty danych. To oczywiście że
powinien być w tym sensie gotowy, bo dane często zbiera się
długo i kosztownie, wiec trzeba bardzo dbać o dane.

Można zrobić taki rozwiązanie, że jak jeden wątek chce plik do
zapisu, to FS czeka aż wszystkie inne wątki zamkną plik. A jak
już jakiś wątek ma plik otwarty do zapisu, to FS nie pozwoli
otworzyć pliku w żadnym trybie. Ale to wyklucza całkiem bezpieczną
sytuację, gdy N wątków pisze i czyta każdy do swojej SIZE/N
części. Po co sobie odbierać takie możliwości i to dodatkowym
nakładem pracy - ja nie wiem.


> > Ale generalnie
> > na tym właśnie polega problem: kilka wątków pracuje na tych samych
> > danych, zakładają że dane mają określoną wartość. Gdy jeden wątek dane
> > zmodyfikuje, to pozostałe już pracują na błędnym założeniu. Dlatego
> > robi się to co napisałem: jeśli jeden wątek zapisuje dane, to może
> > pracować tylko ten jeden wątek, ale do odczytu może być dowolnie wiele.

> Nieprawda. Jeśli jeden watek zapisuje jakas częśc pliku, inny może
> zapisuwać inną część tego samego pliku. DB często tak robią.

Dlatego pisałem NA TYCH SAMYCH DANYCH, a INNE CZĘŚCI PLIKU to już
nie są TE SAME DANE.

> Granulacja jest więc dokładniejsza niż 1 plik. Co oznacza w naiwnym
> podejściu bardzo dużo muteksów na każdy kawałek pliku lub skomplikowany
> mutex z emulacją submutexów.

Nie wiem... Dla mnie to brzmi trochę jak mieszanie rozwiązania szczegółowego z
ogólnym. W szczegółowych zastosowaniach to programista wie które operacje
powinny być atomowe i uzyskuje taki efekt poprzez synchronizację wątków.
Jak ogólnie uzyskać taki efekt? System by musiał dawać dostęp do zapisu lub
do odczytów poszczególnych zbiorów bitów. Użytkownik by musiał to zgłaszać
do systemu. A takie zgłaszanie jest tożsame z synchronizacją przy pomocy
mutexów...

Są jeszcze transakcje, wszystkie wątki próbują czytać i pisać do wszystkiego, a
system sprawdza czy transakcje nie kolidują ze sobą. Jeśli któryś wątek otrzyma
od systemu informację o kolizji, to musi wznowić swoje działanie z uwzględnieniem
tego, że ostatnia transakcja się nie udała - innymi słowy, aplikacja musi być
przygotowana na możliwość nie powodzenia się transakcji. W minimalnej wersji
chociaż musi się wywalić i użytkownik musi ją wznowić.

> Przypuszcam że w ogóle sytuacja że zapisujemy ten sam kawałek pliku
> równolegle z dwóch wątków jest jak najbardziej dopuszczalna. Co najwyżej
> będzie race condition na dane, ale sam plik będzie dalej poprawny z
> punktu widzenia fs.

To brzmi sensownie! Jak programista nie zrobił poprawnie synchronizacji
wątków to jego problem.

> >> bo to wiem. Interesuje mnie jak działa zapewnianie spójności danych w fs
> >> które dla usera wygląda jak typowy zasób krytyczny pilnowany przez mutex.
> > Ale kto powiedział że jest takie zapewnienie?

> W fs jest. Wątek A kasuje plik, wątek B czyta ten sam plik, wątek C
> właśnie go otwiera. I nie ma race conditions na poziomie fs, tam dane są
> spójne i stan jest atomowy.

No tak, głupio byłoby, gdyby z powodu złej synchronizacji wątków rozleciał
się system plików. A czy dane w plikach są poprawne/spójne czy nie - to już 
zależy od poprawności aplikacji.


> > Jeśli dwa wątki zaczną
> > czytać i pisać dane, to zepsują spójność danych w pliku, chyba że OS
> > nie pozwoli otworzyć pliku do zapisu gdy jest może to spowodować
> > utratę spójnośći.
> To tak nie działa. POnadto rozróznijmy: race condition w aplikacji to
> coś innego niż race condition w fs. W tym drugim przypadku masz taką
> sytuację setki razy na sekundę w swoim PC.
> >> Potrzebuje literatury z teorii działania systemów plików. Wygdybać mogę
> >> sobie cokolwiek, ale konkuruje z dziesięcioleciami eksperymentów ludzi
> >> mądrzejszych ode mnie.
> > Może jest coś wartościowego?
> > https://www.google.com/search?channel=fs&client=ubun
tu&q=systemy+plik%C3%B3w+literatura

> Obawiam się czy aby nie jest tylko od strony użytkowej. Ogólnie
> obejrzałem spisy kilkunastu książek z tego tematu i jak na razie nie
> widzę nic o budowie wewnętrznej. Być może coś przeoczyłem.

Nie wiem jaka jest budowa wewnętrzna, ale mi się mocno narzuca to
co już pisałem: zwykła komórka pamięci do której w jednej chwili
ma dostęp do jeden wątek.

A budowa wewnętrzna dzienników to jest po prostu spis operacji i
kopia danych które w razie usterki będzie trzeba odtworzyć.

Pozdrawiam

do góry

On 08/02/2021 14:24, M.M. wrote:
>> To dopuszczalna sytuacja. fs ma być na nia gotowy.
> Trudno sie rozmawia, nie wiem co dla Ciebie znaczy że FS
> ma być gotowy. Skąd FS ma wiedzieć, czy to nie jest zaplanowane
> działanie programisty?

Ma nie wiedzieć. Jedyne co od niego oczekuje to to że nie rozwali sobie
wewnętrznych struktur kiedy dwa wątki będą starały się jednoczesnie
powiekszyć długość pliku albo skasować go w tym samym momencie.

> Pracują np. dwa wątki. Jeden pisze do
> pliku, drugi kasuje plik. Jeśli jeden najpierw zapisze, a drugi
> skasuje - to pliku nie będzie. Jeśli najpierw skasuje, a
> potem dojdzie do próby zapisania, to też nie będzie pliku - fs
> zwróci po prostu błąd zapisu.

Super. Tego właśnie oczekuje. Ma się nie rozsypać. To że w danych jest
sieczka, to problem aplikacji, nie fs.

> Można zrobić taki rozwiązanie, że jak jeden wątek chce plik do
> zapisu, to FS czeka aż wszystkie inne wątki zamkną plik.

O nie.

>> Nieprawda. Jeśli jeden watek zapisuje jakas częśc pliku, inny może
>> zapisuwać inną część tego samego pliku. DB często tak robią.
> Dlatego pisałem NA TYCH SAMYCH DANYCH, a INNE CZĘŚCI PLIKU to już
> nie są TE SAME DANE.

To żadna róznica. fs nie obchodzi co i gdzie zapisuje. Jeśli ktoś
zapisuje te same dane pikoseundę później to nie jest problem fs.

> Nie wiem... Dla mnie to brzmi trochę jak mieszanie rozwiązania szczegółowego z
> ogólnym. W szczegółowych zastosowaniach to programista wie które operacje
> powinny być atomowe i uzyskuje taki efekt poprzez synchronizację wątków.

Nie rozmawiamy tutaj o kliencie tego fs. W nim ta wiedza istnieje.

W fs nie ma żadnej wiedzy o atomowości operacji na plikach. Jedyne co
wymagam od niego to fakt że "open" zadziała atomowo, "close" zadziała
atomowo, "rm" itd. Ma pozwolić na 2x write jednocześnie w to samo
miejsce i się nie rozlecieć.

> A budowa wewnętrzna dzienników to jest po prostu spis operacji i
> kopia danych które w razie usterki będzie trzeba odtworzyć.

To zdecydownie nie wygląda tak prosto w kodzie ext4...

do góry

On Monday, February 8, 2021 at 2:57:15 PM UTC+1, heby wrote:
> On 08/02/2021 14:24, M.M. wrote:
> >> To dopuszczalna sytuacja. fs ma być na nia gotowy.
> > Trudno sie rozmawia, nie wiem co dla Ciebie znaczy że FS
> > ma być gotowy. Skąd FS ma wiedzieć, czy to nie jest zaplanowane
> > działanie programisty?

> Ma nie wiedzieć. Jedyne co od niego oczekuje to to że nie rozwali sobie
> wewnętrznych struktur kiedy dwa wątki będą starały się jednoczesnie
> powiekszyć długość pliku albo skasować go w tym samym momencie.

I chcesz żeby ktoś podpowiedział Ci rozwiązanie jak to wydajnie
zrobić żebyś mógł konkurować z 50letnim doświadczeniem projektantów
systemów plików ;-) To ja się nie odważę pomagać. Ale jakbyś 
chciał pierwsze lepsze rozwiązanie, to bym się odważył podpowiedzieć,
że można zrobić koleję zadań. Zadania do kolejki będą dodawawane
przez aplikacje klienckie. Natomiast system plików z kolejki w N
wątkach będzie pobierał zadania. Jednakże, jeśli jeden wątek
otrzyma zadanie file_1, dotyczące pliku 'file' i w kolejce pojawi
się zadanie file_2, dotyczące tego samego pliku 'file', to algorytm
XYZ będzie musiał zdecydować, czy zadanie jest krytyczne dla bezpieczeństwa
struktury danych, czy też nie. Jeśli nie, to będzie musiał czekać
aż wątek obsługujący zadanie file_1 zakończy działanie i dopiero
potem przydzielić zadanie file_2. Algorytm XYZ wymaga zastanowienia...
W najprostszej wersji zapis do jednego pliku można robić równolegle,
bo aplikacja kliencka powinna zadbać o to, aby zapisy były bezpieczne.
Podobnie odczty można robić w wielu wątkach. Natomiast odczyt musi
czekać aż wszystkie zapisy się zakończą. Zapis też musi czekać aż
wszystkie odczyty się zakończą. Potem wyjątek, jeśli zapis i odczyt
pochodzi z różnych procesów/wątków, to może być zrównoleglany, bo o to
aplikacja kliencka już powinna zadbać. A zmiana rozmiaru plików...
nie wiem... chyba powinna być traktowana jako zapis.

Dodam, nie polegaj szczególnie na tym, wymyśliłem to w chwili
pisania tego posta, nigdy nic nie czytałem o systemach plików.
Poza tym to jest bardzo ogólnikowe, w praktyce dojdzie pierdylion
szczegółów.



> > Pracują np. dwa wątki. Jeden pisze do
> > pliku, drugi kasuje plik. Jeśli jeden najpierw zapisze, a drugi
> > skasuje - to pliku nie będzie. Jeśli najpierw skasuje, a
> > potem dojdzie do próby zapisania, to też nie będzie pliku - fs
> > zwróci po prostu błąd zapisu.

> Super. Tego właśnie oczekuje. Ma się nie rozsypać. To że w danych jest
> sieczka, to problem aplikacji, nie fs.

Jeśli chesz to implementować pod konkretne zastosowanie, to może
się też rozwalić FS, bo będziesz wiedział że dana kombinacja
operacji nigdy nie nastąpi i w praktyce jednak się nie rozwali.

> > Można zrobić taki rozwiązanie, że jak jeden wątek chce plik do
> > zapisu, to FS czeka aż wszystkie inne wątki zamkną plik.

> O nie.

Przydatność zależy od konkretnego zastosowania.



> >> Nieprawda. Jeśli jeden watek zapisuje jakas częśc pliku, inny może
> >> zapisuwać inną część tego samego pliku. DB często tak robią.
> > Dlatego pisałem NA TYCH SAMYCH DANYCH, a INNE CZĘŚCI PLIKU to już
> > nie są TE SAME DANE.
> To żadna róznica. fs nie obchodzi co i gdzie zapisuje. Jeśli ktoś
> zapisuje te same dane pikoseundę później to nie jest problem fs.
> > Nie wiem... Dla mnie to brzmi trochę jak mieszanie rozwiązania szczegółowego z
> > ogólnym. W szczegółowych zastosowaniach to programista wie które operacje
> > powinny być atomowe i uzyskuje taki efekt poprzez synchronizację wątków.
> Nie rozmawiamy tutaj o kliencie tego fs. W nim ta wiedza istnieje.

Zaczęliśmy rozmowę od tego, że głupio gdy aplikacja zapisuje dane w
katalogu a nie w pliku, więc zahaczaliśmy też mocno o klienta.



> W fs nie ma żadnej wiedzy o atomowości operacji na plikach.

Ale Ty chcesz pisać swój, bardzo specyficzny, zoptymalizowany
pod konkretną aplikację - tak zrozumiałem.


> Jedyne co
> wymagam od niego to fakt że "open" zadziała atomowo, "close" zadziała
> atomowo, "rm" itd. Ma pozwolić na 2x write jednocześnie w to samo
> miejsce i się nie rozlecieć.

To w pierwszym akapicie tego posta dałem zarys synchronizacji, a
chyba w pierwszym poscie zaproponowałem strukturę danych (tam
gdzie byłą lista list, nagłówek pliku, nagłówki miejsca pustego,
zajętego, itd.) Nic bardziej szczegółowego w trakcie luźnej
rozmowy nie podpowiem.


> > A budowa wewnętrzna dzienników to jest po prostu spis operacji i
> > kopia danych które w razie usterki będzie trzeba odtworzyć.

> To zdecydownie nie wygląda tak prosto w kodzie ext4...

Bo, jak się domyślam, są mocno zoptymalizowane i mają pierdylion
opcji dobieranych w (auto)tuningu i mogą się dostosować do
wielu urządzeń.


Pozdrawiam

do góry

On 08/02/2021 18:35, M.M. wrote:
> I chcesz żeby ktoś podpowiedział Ci rozwiązanie

Nie, aby wskazał gdzie szukać. Wydaje mi się że wiele lat temu migneła
mi ksiązka w tym temacie, anglojezyczna. Nie pamietam tytułu, opisywała
na pewno FAT i jeszcze coś, pod kątem detali implementacji. Miałem w
ręku i tyle ją widziałem.

>> W fs nie ma żadnej wiedzy o atomowości operacji na plikach.
> Ale Ty chcesz pisać swój, bardzo specyficzny, zoptymalizowany
> pod konkretną aplikację - tak zrozumiałem.

To że coś jest embedowalne, nie oznacza że nie ma być abstrakcyjne. Ma
być. FS ma nie mieć wiedzy o sposobie uzycia, ma byc odporny na dziwne
uzycie.

do góry

On Monday, February 8, 2021 at 6:41:48 PM UTC+1, heby wrote:
> On 08/02/2021 18:35, M.M. wrote:
> > I chcesz żeby ktoś podpowiedział Ci rozwiązanie
> Nie, aby wskazał gdzie szukać. Wydaje mi się że wiele lat temu migneła
> mi ksiązka w tym temacie, anglojezyczna. Nie pamietam tytułu, opisywała
> na pewno FAT i jeszcze coś, pod kątem detali implementacji. Miałem w
> ręku i tyle ją widziałem.
> >> W fs nie ma żadnej wiedzy o atomowości operacji na plikach.
> > Ale Ty chcesz pisać swój, bardzo specyficzny, zoptymalizowany
> > pod konkretną aplikację - tak zrozumiałem.
> To że coś jest embedowalne, nie oznacza że nie ma być abstrakcyjne. Ma
> być. FS ma nie mieć wiedzy o sposobie uzycia, ma byc odporny na dziwne
> uzycie.

Gdzie szukać - nie wiem. To co mi zdrowy rozsądek podpowiedział w przeciągu
kilku postów i 30 minut zastanowienia - napisałem. Więcej pomóc nie potrafię,
sam bym musiał poczytać, ale do czytania nie mam motywacji w świecie pełnym
Sqlite, PostgreSQL, MongoDB, BDB, Redis i czego tam jeszcze; o gotowych systemach
plików nie wspomniawszy.

Ja może bym chciał poczytać książkę o optymalizacji powyższych baz danych z
uwzględnieniem nowoczesnych dysków SSD na złączu M.2, dysków RAM, macierzy
dyskowych i to wszystko w połączeniu z doborem rodzaju i parametrów systemu plików.

Pozdrawiam

do góry

W dniu 2021-02-08 o 18:41, heby pisze:
> On 08/02/2021 18:35, M.M. wrote:
>> I chcesz żeby ktoś podpowiedział Ci rozwiązanie
>
> Nie, aby wskazał gdzie szukać. Wydaje mi się że wiele lat temu migneła
> mi ksiązka w tym temacie, anglojezyczna. Nie pamietam tytułu, opisywała
> na pewno FAT i jeszcze coś, pod kątem detali implementacji. Miałem w
> ręku i tyle ją widziałem.

Trochę stara, ale może ta byłaby odpowiednia:
Dominic Giampaolo ,,Practical File System Design", Morgan Kaufmann 1999
Autor omawia system plików BFS z BeOS.
Do znalezienia w necie, Google wyrzuca pdf-a jako pierwszy wynik w
wyszukiwaniu...

Poza tym można szukać w książkach o systemach operacyjnych, np.:

Tanenbaum, Woodhull ,,Operating Systems Design and Implementation", 3rd
ed, to jest o implementacji systemu MINIX, jest ponad 100 stron o
systemie plików + kod źródłowy.

Tannenbaum ,,Modern Operating Systems", jest 70 stron o systemach plików.

Silberschatz ,,Operating System Concepts", 9th ed, 2012 jest ponad 150
stron o ,,storage management", w tym podrozdział ,,file system
implementation" 40 stron.

Remzi, Arpaci-Dusseau ,,Operating Systems Three Easy Pieces", rozdział
,,persistence" ma ponad 150 stron.

Ciekawe rzeczy można też znaleźć w książkach o implementacji baz danych,
w końcu plik bazy danych ze zbiorem rekordów i indeksem nie różni się w
swojej istocie zbytnio od systemu plików.

Są też z wydawnictwa O'Reilly (widziałem tylko tytuły, nie przeglądałem):
Rajeev Nagar ,,Windows NT File System Internals: A Developer's Guide"
Stan Mitchell ,,Inside the Windows 95 file system"

do góry