🚀 go-pugleaf

On 07/04/2021 12:25, J-23 wrote:
> Tak sie składa że na codzień pracuje na plikach które mają fizycznie 
> ponad 100 GB i jakoś nie mam dylematow jak Ty

Otóż to.
- Jakie Pan ma kwalifikacje na lekarza?
- Żyje od 40 lat i dobrze mi to wychodzi

> To znajdziesz jak w 80% napisać taką strukture ale podobno znasz ten 
> format wiec jak to jest? Znasz czy nie?

Tam są wie rzeczy: struktura zapisu bloków symulowanego dysk tak, aby 
plik mógł rosnąc i redukować dynamicznie.

To załatwia VM.

I jest nastepna warstwa, to filesystem w systemie gościa.

Maszyna ma w nosie co gość robi z emulowanym dyskiem i jaki ma na nim 
filesystem. Ona tylko emuluje urzdzenie blokowe.

Innymi słowy maszyna wirtualna zajmuje sie tą łatwijeszą częscią.

> To że byly komercyjne nie znaczy że wiedza ci po nich nie pozostała i 
> nie możesz na tej wiedzy bazować. To co napisałeś brzmi "wiem jak dziaja 
> filesystem ale nie moge tej wiedzy wykorzystać bo korzystalem z niej 
> komercyjnie w projekcie" Smiech na sali :)

Nie rozmuiesz. Prosty FS mogę sobie napisać. Pliki, duperele.

Prawdziwe ciekawoski kryją się w lockach, wielodostepie, kronikowaniu, 
GC i trim, translacji bloków w tle.

>> Spróbuj odczytać "fragment" pliku ZIP, popracować w pamięci i zapisać 
>> ponownie w środku, o innej długości (bosię inaczej spakował). Daj 
>> znać, jak poszło.
> Nie rozumiesz że to co ty nazywasz plikiem to dla pamieci jest takim 
> samym blokiem pamieci jak wszystko inne

I ma takie same problemy jak trzymanie pliku ZIP w pamięci i operowanie 
na nim w realtime. ZIPy to nie filesystemy tylko storage. Pakuje się raz 
i koniec.

>> Widać że nie masz sladu pojmowania o czym mowa. Wyobraź sobie 
>> std::vector i dwa wątki. Czyje zadanie jest zrobić synchronizacje? 
>> Kontrolera pamięci, który nei ma pojęcia o atomowości operacji, czy 
>> programista?
> Widać masz za małe doświadczenie na wątkach... trudno nie będe Ci tego 
> tlumaczył bo znowu nie zrozumiesz i stwierdzisz że nie o tym mowie co ty 
> uważasz

No więc synchronizacje std::vector rozwiązuje kontroler pamięci czy 
algrotym programu? Analogia wielodostępu do pliku wręcz idealna.

> Znowu kłania się brak wiedzy o wątkach

Ale nie odpowiedziłeś na pytanie. Kto gwarantuje spójnośc danych w 
pliku, jesli dorywaja się do niego dwa procesy na raz. Mówje o spójności 
tego mitycznego "formatu" który ma byc rozwiązaniem wszelakich problemów.

> Zastanów się i odpowiedz na jakim to ma środowisku działać bo raz 
> piszesz że nie ma to większego znaczenia a drugi razem piszesz o 
> operacji na wątkach.

Struktura ma być odporna na wielodostęp. Inaczej: dowolna operacja na 
pliku wykonana w procesie A ba być widoczna spójnie w procesie B. 
Gwarantuje to *prawie* każdy filesystem.

>> Konkretne bajty można usuwać z pliku? Owszem, jest pojęcie "pliku z 
>> dziurami" na Unixach, ale to nie działa jak myslisz.
> To działa jak myśle tylko tyle że sama operacja trim nie zalatwia ci 
> sprawy jak ty myslisz tutaj są potrzebne dodatkowe operacje o ktorych ty 
> nie zdajesz sobie sprawy

:D

>> Zabawne. Bo tak nie jest. Mój plik fizyczny to taka "partycja", tylko 
>> że zamiast bycia kawałkiem dysku, jest całym plikiem. I jeszcze raz: 
>> kronika trzymana jest w środku partycji. Przynajmniej w popularnych fs 
>> które znam.
> Trzymana na partycji. Jesteś pewien? Otóż takie pytanie to po co te 
> kroniki są i co w wypadku uszkodzenia partycji? Pomyśl chwile

Nic. Do kosza. Kronikwanie nie słuzy do ratowania dupy w przypadku padu 
fizycznego dyku/partycji. Pomyliłeś z RAID.

> Bo teraz gadasz głupoty z rozpędu lub nie wiesz do czego te kroniki sluza

Wydaje mi się że wiem dostatecznie. Podpowiem Ci: do poprawiania 
miękkich błedów, takich jak nieoczekiwane znikniecie zasilania. Dzięki 
kronikom można okreslić jakiś poziom pewności, że sekwencyjny zapis 
zadziałał w przewidywalny sposób, a nie wynikajacy z przypadku ułożenia 
cache dysku lub tego że flash nie zdążył się na czas skasować.

>>> Pierwsze wersje będa napewno nie wydajne ale musisz zacząć coś pisać 
>>> a potem to optymalizować bo inaczej się zamotasz
>> Bzdura.
> A to Ciekawe od ręki wiesz ze to co piszesz jest super optymalne. 
> Gratuluje :)

Zabieranie się za robotę a potem "optymalizowane" uważam za żałosne 
podejście studenta na zaliczenie. Najpier należy zdobyć wiedzę, potem 
pracować wiedząc co czyniąć.

>> No ale ja wiem jak jest zbudowany. Nijak to nie rozwiązuje tych 
>> problemów z twojego zakresu "itd" które tak usilnie starasz się 
>> ignorować.
> Dziwne nagle Filesystem nie rozwiązuje tego co chcesz.

To proste, mistrzu. Twój plik z maszyny wirtualnej to nie filesystem. 
Więc nie rozwiązuje problemów. Twoje "zrób se pliki" nie rozwiązują 
problemów, bo magia jest w "itd" które zgrabnie pomijasz mocą swojej 
ignorancji.