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