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

do góry

On 07/04/2021 14:29, J-23 wrote:
>> Nic, bo nie potrzebuję katalogów.
> Ty to co nazywasz katalogiem jest zbiorem bajtów zrozum to wreszcie. Bo
> jak widać tego nie pojmujesz

Nie pojmuję, bo ich nie potrzebuje.

> Twoim rozwiązaniem jest wziąć adoptować system plikow i go przenieść na
> to by pracował na pliku a nie na fizycznym dysku

Wow. Prawdziwy postęp w Twoim pojmowaniu, zaczynasz czaić bazę. Tak,
mógłbym tak zrobić.

Jesty tylko detal: 99% filesystemów pracuje ze stałym rozmiarem kontenera.

O ile mogę napisać warstwę trimującą pod spodem, to mam nadzieje że
redukujac swoją ignorancję w temacie "jak się pisze filesystemy" może
się okazać że to jest zrabialne za jednym razem z fs.

> Tylko ty nie pojmujesz tego że to wiąże sie ze zbudowaniem odpowiedniej
> struktury

:D Znowu ta mistyczna struktura. Zdardź wreszcie jak ona wygląda.

> A no gdzie szukać informacji jak to zbudować - skoro potrzebujesz
> funkcjonalności pliku to zobacz jak on jest zbudowany np na FAT czy
> innym systemie wyciągnij wnioski i pisz

Ale FAT jest gówno wart.

> Dlaczego piszę że to moim zdaniem system pliktów to jest dużo na wyrost
> bo to co potrzebujesz da się zrobić w dużo mniej skomplikowany sposob
> niz Filesystem

I oczywisćie *jeszcze* nie ujawniłeś tego światu. Ale czekamy.

> Zrob prosty test zapakuj dwa pliki w jeden tylko nie zipem :) i co nie
> da się na nich pracować - da tylko musisz wiedzieć jakie to są pliki i
> co chcesz z nich wyciągnąć a ty poki co nic nie wspominasz jakiego typu
> sa pliki ktore będziesz pakował czy znasz format tych plikow?

Genialne. Zlepmy te wszystkie pliki w OS, na ch... komu filesystemy.

Może podpowiem: powiększ środkowy plik o bajt.

I określ co to jest "zapakuj".

> Brak jest podstawowej informacji co ty chcesz robić

Jak się nie czyta postów, szczególnie pierwszego, to faktycznie brak.

> Zapakować pliki w jeden to wystarczą strumienie i taką informacje żeś
> dostal ode mnie

Genialne. Dowolny problem można rozwiązać poprzez zignorowanie trudnych
aspektów a nastepnie podając trywialne rozwiązanie.

Zrobisz karierę w polityce.

> Napisales pracować na plikach czyli co z nimi robić
> 1. Obcinać/sklejać modyfikować a jeśli modyfikować to jak?

Normalnie. file.writeBytes( buf, count );

> 2. Uruchamiać te pliki

Nie.

> moge jeszcze dużo rzeczy wypisać o których nawet słowkiem nie
> wspomnialłeś a są istotne

Wspomniałem o wszystm co istotne.

> Pytałem w którymś poście budujesz symulator dysku - cisza brak odp

To nie symulator dysku. Symulator dysku da się zrobić jako dd
if=/dev/zero of=dysk bs=512 count=1000. Działa znakomicie.

> Domyslam sie że nie ale wypisanie 4 czy 5 punktow ktore ująłeś w którymś
> poscie i pracowanie na tym to mi do zrobienia czegoś takiego wystarczą
> strumienie.

Nie wystarczą.

> Kwestia tylko co rozumiemy przez prace na plikach o ktorej
> nie wspomniales ani slowem

Padało to w wątku niezliczoną ilość razy.

> Widzisz i sam nie wiesz co czytasz. Bo dla mnie to nie jest poskładanie
> protonow i neutronow a zdobycie doświadczenia na bazie tego co ktos
> stworzył. Ty probujesz dostać gotowy pomysł i adoptować go do swoich
> potrzeb a tak to nie dziala.

Dokładnie. A jak świeci słońce, to jest dzień. Można mnie cytować.

do góry

On 07/04/2021 14:58, J-23 wrote:
>> Otóż to.
>> - Jakie Pan ma kwalifikacje na lekarza?
>> - Żyje od 40 lat i dobrze mi to wychodzi
> Co to wnosi do rozmowy - nic.

Tak jak i cała reszta tych dywagacji, przeciez ja ciągnę tą dyskusję z
powodów sportowych.

> A czym jest dysk?

Czymkolwiek co ma stan potrafiący chwilę przetrwać.

> Ze tak zapytam bo może inaczej rozumiemy urządzenia
> blokowe

Rozumiemy tak samo. Rozumiemy jako disc[blockIndex]=block.

Pod spodem może być stacja dysków Atari 1050, jeśli to ma znaczenie.

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

Ale tam nic nie ma poza tranaslacją bloków.

>> Prawdziwe ciekawoski kryją się w lockach, wielodostepie, kronikowaniu,
>> GC i trim, translacji bloków w tle.
> Czemu tego nie sprawdzisz w innych Filesystemach

Ponieważ dano to zrobiłem. Wnioski są takie że optymalizacje są na tyle
głebokie i rozległe, że traci się obraz i skrajnie utrudnia analizę. Na
ten przykład przegladałem ext4. Bez dokumentacji nie byłem w stanie się
w tym poruszac, z dokumentacją byłem w stanie pojąć 10% całości.

> Nie rozumiesz że Filesystem to tylko struktura

O, to akurat rozumiem.

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

I one pozwalają na dynamiczną modyfikację swojej zawartości z
trimowaniem i wielodostępem? Wow.

> mam 3 obrazy zapisane w pliku bin i teraz zagadka jak do obrazka numer 2
> dodać kwiatek?

To łatwe. Proponuje trudniejsze: jak dodać czwarty obrazek z kwiatkiem
pomiędzy pierwszy i drugi.

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

Wystarczająca.

> Od kiedy Filesystm jest gwarantem spójności pliku?

Od czasu posiadania kroniki. Dane zapiywane są albo w całości jakiejś
jednostki albo nie. Są również albo zapisywane sekwencyjne, albo tracone.

W przypadku systemów bez kronikowania i cache, możlie sa przykre
sytuacje kiedy write zadziała niesekwencyjnie zapisując kawałki pliku w
róznych miejscach a winnych nie i nie ma nad tym kontroli.

> Są narzedzia do tego
> FS nic o spojnosci pliku nie wie

Ależ wie.

Dam Ci taki przykłąd.

Proces A kasuje plik. Wymaga to zmiany kilkudziesięciu bloków na dysku.

Proces B otwiera ten sam plik. Filesystem zapewnia że albo go otworzy
albo nie. Nie ma sytuacji że "otworzy w trakcie kasowania przez inny
proces i częśc danych będzie popsuta".

To jest spójność. Nie ma stanów niepewnych lub wręcz popsutych.

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

Powyżej wyjaśnienie.

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

Przepraszam, ale pękam ze śmiechu od przedwczoraj. Nie wiem czemu. Może
to z powodu pogody.

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

U mnie chyba inny internet jest:

"A journaling file system is a file system that keeps track of changes
not yet committed to the file system's main part by recording the
intentions of such changes in a data structure known as a "journal",
which is usually a circular log. In the event of a system crash or power
failure"

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

Wiem, że wiesz, że wiem.

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

Napisałeś ręcznie coś podobnego do ntfs-3g? Wow. To sorry. Możesz mieć
rację we wszystkim, jesteś moim idolem. I to wszystko w OpenPascalu?

do góry

W dniu 2021.04.07 o 15:21, heby pisze:
> On 07/04/2021 14:58, J-23 wrote:
>> 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.
>
> Napisałeś ręcznie coś podobnego do ntfs-3g? Wow. To sorry. Możesz mieć
> rację we wszystkim, jesteś moim idolem. I to wszystko w OpenPascalu?
>

Nie podobnego do ntfs-3g (i pozostałych elementow ktore wymienilem) ale
wykorzystując wiedze na podstawie analizy zródeł a to różnica

A podobne rozwiązanie do Twojego tylko ja nie oznaczam że coś jest
plikiem czy katalogiem

wspomniałeś w drugiej odnodze tego wątku cytując "Może podpowiem:
powiększ środkowy plik o bajt."

Ja go właśnie tak powiekszam nawet o kilka dziesiąt mega i moge również
zmiejszać ale ty nadal tego nie czaisz - znam doklładnie co chce tam
wstawić a nie tak jak u ciebie odp że to "plik" mowiąc plik to akurat
nic nie mowi. Twierdzisz że podałeś kilkadziesiąt razy w swoich postach
co to ma być - nie podałeś ani razu. Tak samo nie wspomniałeś o api na
które się powołujesz że jest niby w glownym w poście.

A gdzie ja napisałem że w Object Pascalu to po pierwsze. Masz jakieś
urojenia - lub co najmniej problem z czytaniem ale to już zauważyłem dawno

Podsumowując życzę powodzenia bo nie da się rozmawiać konkretnie nie
udzielając odpowiedzi na pytania. Nie tylko ja to zauważyłem tutaj ale
mniejsza o to

Pozdrawiam
J-23

do góry

W dniu 14.01.2021 o 13:31, heby pisze:

> Dzięki temu mogę w jednym pliku trzymac w środku wiele plików,
> bezustannie je czytajac i zmieniając. Ułatwi mi to pracę, ponieważ pliki
> te są trzymane razem, user nie może nic w nich popsuć, nie muszę
> bezustannie pakować/rozpakować jak robi np. OpenOffice (u nich
> kontenerem jest packer). Od razu gotowe do pracy.

Może SQLite?

--
pzdr
Roman

do góry

On 09/04/2021 12:04, Roman Tyczka wrote:
> Może SQLite?

Mam tak w celach zatkania czymś interfejsu. Ale SQLite jest absurdalnie
powolne przy czytaniu random access pliów i jedyna metoda synchronizacji
mutithread jest *chyba* implementowana dość naiwnie sądząc po zachowaniu.

Tak czy inaczej taka zatyczka na API się nie sprawdza za dobrze,
produkcyjnie. W testach ok, jako mock.

do góry

W dniu 09.04.2021 o 13:42, heby pisze:
> Mam tak w celach zatkania czymś interfejsu. Ale SQLite jest absurdalnie
> powolne przy czytaniu random access pliów i jedyna metoda synchronizacji
> mutithread jest *chyba* implementowana dość naiwnie sądząc po zachowaniu.
>
> Tak czy inaczej taka zatyczka na API się nie sprawdza za dobrze,
> produkcyjnie. W testach ok, jako mock.

To idźmy dalej tym tropem, może Firebird Embedded? :-)

--
pzdr
Roman

do góry

On 09/04/2021 22:55, Roman Tyczka wrote:
>> Tak czy inaczej taka zatyczka na API się nie sprawdza za dobrze,
>> produkcyjnie. W testach ok, jako mock.
> To idźmy dalej tym tropem, może Firebird Embedded? :-)

Wiesz, ja nie tylko chce funkcjonalność, przydała by się też prędkośc.
mmap by się przydał w zasadzie. W przypadku sprytnie rozwiązanego
filesystemu można doprowadzić do sytuacji gdy rawdata z filesystemu jest
widziane wprost w pamięci, w miarę liniowo.

do góry