🚀 go-pugleaf

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