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