🚀 go-pugleaf

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