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.