W dniu 2021.04.07 o 13:40, heby pisze:
> 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
>

Co to wnosi do rozmowy - nic.

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

A czym jest dysk? Ze tak zapytam bo może inaczej rozumiemy urządzenia
blokowe

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


Tak ale skąd czerpie info właśnie z tego pliku co tlumacze ci byś tam
zajrzał

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

Czemu tego nie sprawdzisz w innych Filesystemach chociać juz po
ciekawostkach widać że to wykracza po za tą tematyke ale ty tego nie
rozumiesz (Nie rozumiesz że Filesystem to tylko struktura) reszta jest
gdzie indziej

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

Masz uraz do ZIPa że tak sie na nie uparłeś znam kupe innych rozszerzeń
np bin ktore przechowywują inne pliki (poslugując się twoim tokiem
rozumowania)

mam 3 obrazy zapisane w pliku bin i teraz zagadka jak do obrazka numer 2
dodać kwiatek? Ty masz z tym problem ja nie mam problemu znająć
zawartość bin by do obrazka nr 2 dodać kwiatek

Dlatego jest bardzo ważne co w tym pliku twoim ma być ty tylko
odpowiadasz pliki a to troche ogolna odp

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


Od kiedy Filesystm jest gwarantem spójności pliku? Są narzedzia do tego
FS nic o spojnosci pliku nie wie
>
>> 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.
>

Pokaż jakiś przykład bo pierwsze słysze że Filesystem oodpowiada za
spojność - jaką spójność masz na mysli bo moze znowu mowisz o czymś co
zupelnie inaczej się nazywa

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

No wlasnie tylko tyle można zrobić z twoją próbą zbudowania czegokolwiek
- uśmiechnąć się

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

Wpisz "kroniki" w google a dowiesz się po co powstały bo tego nie wiesz.

Inna bajka że co FS są inaczej implementowane

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

Zablysnąłeś wiedzą a ja na to powiem że mało wiesz

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

Ty nie zbierasz ty szukasz pomysłu który adoptujesz do wlasnego roziązania

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

Ty pomijasz więcej niż ci sie wydaje ale cóż nie ja mam problem ale ty.
Ja akurat pracuje na czymś podobnym co chcesz osiągnąć - zbudowałem to
od zera wzorująć się na FAT32 i ntfs-3g i wlasnie VDI no ale co ja tam
wiem według ciebie to jest za mało.

Pozdrawiam