🚀 go-pugleaf

On Thursday, January 14, 2021 at 1:31:18 PM UTC+1, heby wrote:
> Cześć. 
> 
> Poszukuje inspiracji a być może gotowca. Ale to trudno powiedzieć. A 
> chodzi o coś takiego: 
> 
> Implementacja abstrkacyjnego filesystemu pracującego na urzeniau 
> blokowym, do którego dostęp zapewniam ja, przez stosowane abstrkacje. 
> Wykorzystać było by fajnie, ale najważniejsze to możliwośc podejrzenia 
> rozwiązań. 
> 
> Wiec to tak powinno wyglądać: 
> 
> struct IFooFileSystem 
> { 
> std::shared_ptr< IFile > openFile( std::string cosnt& _fileName, Flags 
> _flags ); 
> 
> bool fileExist( std::string const& _fileName ); 
> 
> [...] 
> }; 
> 
> struct IBlockDevice 
> { 
> std::shared_ptr< Block > readBlock( BlockIndes _index ); 
> 
> void writeBlock( BlockIndes _index, Block& _block ); 
> }; 
> 
> struct IFile 
> { 
> void read(...); 
> void seek(...); 
> [...] 
> } 
> 
> std::shared_ptr< IFooFileSystem > 
> createFileSystem( myBlockDevice ); 
> 
> Coś w ten deseń, czyli to ja dostaczam abstrakcje robiącą I/O na 
> poziomie block/cluster a kod realizuje wysokopoziomowe operacje plikowe. 
> 
> To nie musi być z czymkolwiek kompatybilne, nawet lepiej gdyby nie było. 
> Musi być natomist komplenie nie zależne od czegokolwiek, czy to systemu 
> czy zewnatrznych biblitek. I thread safe, będę jednoczesnie czytał i 
> zapisywał wiele "plików" z róznych wątków. W zasadzie poza "plikami" 
> reszta kompletnie zbędna, nie interesują mnie atrybuty czy nawet 
> katalogi. Mocno uproszczony filesystem, coś w rodzaju wielu niezależnych 
> strumieni w jednym kontenerze. 
> 
> Mogę to napisać samodzielnie, ale zanim to zrobie: ktoś widział taki 
> projekt lub część jakiegoś projektu? 
> 
> Dla zastanawiajacych się po co mi to: 
> 
> Jest *prawdziwy* plik. W moim kodzie jest konwertowany do urządzenia 
> blokowego i wystawiany do tego mechanizmu fiesystemu. 
> 
> 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. 
> 
> Katalog odpada: user może w nim coś popsuć. 
> 
> Ewentualne puchnięcie moża jakoś obejśc pisząc garbage collector 
> trimujący ten "wirtualny filesystem" i przenoszący bloki w tle. 
> 
> Coś podobnego robi np. VirtualBox ale nie chodzi o taki poziom emulacji 
> dysków, to ma byc mała pierdoła do kodu który mam pod kontrolą. 
> 
> Innymi słowy: czy ktoś widział tego typu wirtualny filesystem? 
> Interesują mnie zagadnienia takie jak uproszczony wielodostęp czy 
> realizacja kroniki. Chciałbym je poderzeć, ponieważ nie mam w tym 
> doswiadczenia, pewnie napiszę to mało optymalnie. 
> 
> Projekt Fuse nie nadaje się bez bardzo poważnego wrapowania. Ponadto ja 
> nie potrzebuje wielu filesystemów, potrzebuje tylko jeden, o mało ważnej 
> kompatybilności ze światem zewnętrznym. Taki FooFS.

Jakby to miało być wydajnościowo optymalne, to by wymagało  dużego nakładu pracy, 
wielu prób, tunignu, testów, debugowania... W jakim sensie to by miało być optymalne?


Pozdrawiam

On 05/02/2021 19:42, M.M. wrote:
> W jakim sensie to by miało być optymalne?

Nie musi być optymalne. To tylko optymalizacja user/programista. Z 
jednej strony wszystko w jednym pliku pakowanym ZIPem, z drugiej strony 
milion plików w których user może coś pozmieniać i nieszczęscie gotowe. 
Taki "filesystem w pliku" pozwoli kosztem niewielkiego spadu wydajności 
uzyskać spójny zbiór danych w którym user grzebać nie będzie, nawet 
przypadkiem.

To tak "baza danych" tylko że zamiast tabel w środku sa same bloby... 
obecnie mam właśnie taką emulację, na sqlite. Ale to jest zupełnie 
niepotrzebne, ponadto taki wirtualny filesystem, przy odrobinie wprawy, 
pozwalałby na częsciowe mapowanie plików w pamięć, czego bloby w sql nie 
potrafią.

On Sunday, February 7, 2021 at 12:55:37 PM UTC+1, heby wrote:
> On 05/02/2021 19:42, M.M. wrote: 
> > W jakim sensie to by miało być optymalne?
> Nie musi być optymalne. To tylko optymalizacja user/programista. Z 
> jednej strony wszystko w jednym pliku pakowanym ZIPem, z drugiej strony 
> milion plików w których user może coś pozmieniać i nieszczęscie gotowe. 
> Taki "filesystem w pliku" pozwoli kosztem niewielkiego spadu wydajności 
> uzyskać spójny zbiór danych w którym user grzebać nie będzie, nawet 
> przypadkiem. 
> 
> To tak "baza danych" tylko że zamiast tabel w środku sa same bloby... 
> obecnie mam właśnie taką emulację, na sqlite. Ale to jest zupełnie 
> niepotrzebne, ponadto taki wirtualny filesystem, przy odrobinie wprawy, 
> pozwalałby na częsciowe mapowanie plików w pamięć, czego bloby w sql nie 
> potrafią.

Jakbym musiał zaimplementować ręcznie bliżej nie określone rozwiązanie, to
bym zrobił listę na dysku. Nie wydaje się to szczególnie trudne.

Takich kilka chaotycznych/zgrubnych i nie do końca przemyślanych wskazówek : By trzeba 
zdefiniować rozmiar węzła, nagłówek dla wolnego węzła, nagłówek dla pustego węzła i
nagłówek pliku. W nagłówku pustego byłby adres następnego pustego - czyli lista wolnych
węzłów. W nagłówku pliku adres pierwszego pustego węzła, jeśli by wskazywał na koniec
pliku, to nowy węzeł można utworzyć na końcu pliku przez zwiększenie rozmiaru. Za nagłówkiem
pierwszy węzeł pliku z informacją o systemie plików, czyli nazwa pliku i pierwszy węzeł pliku i
może jakieś dane pomocnicze, jak np. długość pliku, suma kontrolna, może nawet dane 
naprawcze - to już zależne od szczegółowych wymagań. Nagłówek węzła pliku by musiał 
zawierać adres następnego węzła a może także adres następnego 10tego węzła, wtedy
seek dla długich plików zadziałałoby 10 razy szybciej. Zwalnianie węzła można zrobić 
przez wpis do węzła danych z na nagłówka pliku o następnym wolnym węźle, a do nagłówka
pliku przepisujemy informację o nowym pierwszym wolnym węźle. 

Aby znaleźć plik, trzeba przeszukać listę systemu plików. Nazwy plików mogą być też w
danych pliku, a w liście systemu plików tylko funkcje skrótu nazw plików, to powinno 
przyspieszyć wyszukiwanie. 

Odczyt pliku to odczyt danych z pierwszego węzła i skok do drugiego węzła, potem 
odczyt z drugiego i znowu skok do kolejnego.

Optymalizowanie tego, dostosowywanie tego do konkretnego rozwiązania, już takie
łatwe nie jest.

Pozdrawiam
 

On 07/02/2021 15:34, M.M. wrote:
> Takich kilka chaotycznych/zgrubnych i nie do końca przemyślanych wskazówek : By trzeba
> zdefiniować rozmiar węzła,

Dzięki za pomysły. Tak naprawdę najbardziej mnie interesują dwie rzeczy:
1) jak realizuje sie kronikowanie - tak bardziej pod kątem teoretycznym

2) jak realizuej się wielodostep z wątków i locki w systemie.

> Optymalizowanie tego, dostosowywanie tego do konkretnego rozwiązania, już takie
> łatwe nie jest.

Na razie poszukuje inspiracji aby ocenić czy to w ogóle ma sens. 
Wyskrobać sam coś może i wyskrobię, ale głupio robić na starcie szkolne 
błędy.

On Sunday, February 7, 2021 at 7:04:31 PM UTC+1, heby wrote:
> On 07/02/2021 15:34, M.M. wrote: 
> > Takich kilka chaotycznych/zgrubnych i nie do końca przemyślanych wskazówek : By trzeba 
> > zdefiniować rozmiar węzła,
> Dzięki za pomysły. Tak naprawdę najbardziej mnie interesują dwie rzeczy: 
> 1) jak realizuje sie kronikowanie - tak bardziej pod kątem teoretycznym 
> 
> 2) jak realizuej się wielodostep z wątków i locki w systemie.
> > Optymalizowanie tego, dostosowywanie tego do konkretnego rozwiązania, już takie 
> > łatwe nie jest.
> Na razie poszukuje inspiracji aby ocenić czy to w ogóle ma sens. 
> Wyskrobać sam coś może i wyskrobię, ale głupio robić na starcie szkolne 
> błędy.

On Sunday, February 7, 2021 at 7:04:31 PM UTC+1, heby wrote:
> On 07/02/2021 15:34, M.M. wrote: 
> > Takich kilka chaotycznych/zgrubnych i nie do końca przemyślanych wskazówek : By trzeba 
> > zdefiniować rozmiar węzła,
> Dzięki za pomysły. Tak naprawdę najbardziej mnie interesują dwie rzeczy: 
> 1) jak realizuje sie kronikowanie - tak bardziej pod kątem teoretycznym 

W najbardziej podstawowej wersji kronikowanie to rejestr operacji, w przeciwieństwie do
pliku który jest efektem (tychże operacji).  Jeśli mamy cały rejestr operacji, to możemy z
nich odtworzyć cały plik. Plik jest potrzebny tylko ze względów wydajnościowych. Sens
kronikowania jest tylko w połączeniu z transakcjami. Muszą wszystkie operacje z transakcji
trafić do plików, albo żadna. W wielkim skrócie jest utrzymywana kopia do naprawy gdy
nie uda się zamknąć transakcji, albo gdy się uda, ale zasilanie padnie w trakcie przerzucania z
dziennika do zbiorów danych.

> 2) jak realizuej się wielodostep z wątków i locki w systemie.

Z ciekawości zapytam, do czego potrzebujesz takiej wiedzy?


> > Optymalizowanie tego, dostosowywanie tego do konkretnego rozwiązania, już takie 
> > łatwe nie jest.

> Na razie poszukuje inspiracji aby ocenić czy to w ogóle ma sens. 
Ale co ma sens? Pakowanie danych jakiejś aplikacji do jednego pliku - myślę 
że ma sens, wygląda to bardziej elegancko niż do jednego katalogu. Czy
jest sens pisania tego samemu od zera? Nie wiem, zależy jakie są gotowe
rozwiązania, nie potrafię polecić żadnego gotowca. Pisanie do jednego 
katalogu, a potem zip katalogu - też nie głupie, a nakład pracy mały, bo 
zip jest darmowy i dokument będzie od razu skompresowany. 

Natomiast co może mieć sens w kontekście wątków i ich realizacji w 
systemach operacyjnych - to nawet się nie domyślam.


> Wyskrobać sam coś może i wyskrobię, ale głupio robić na starcie szkolne 
> błędy.

To chyba nieuniknione w przypadku ciut większych projektów - chyba że
coś bardzo podobnego robimy po raz któryś.

Pozdrawiam

On 07/02/2021 20:03, M.M. wrote:
>> 2) jak realizuej się wielodostep z wątków i locki w systemie.
> Z ciekawości zapytam, do czego potrzebujesz takiej wiedzy?

Nie chcę 1 mutexa na wszystko. Wątków dostepowych będzie wiele. Skoro fs 
są używane praktycznie wyłącznie w środowiskach wielowątkowych, to 
przypuszczam że nie jest to jakaś specjalnie trudna sprawa. Znowu: mam 
jakieś pomysły, ale pewnie naiwne.

Ba, zerknąłem w kod kilku fs, ale ciezko znaleźc jakieś anstrakcje, 
zazwyczaj się silnie zoptymalizowane i struktura traci sie w 
optymalizacjach.

>> Na razie poszukuje inspiracji aby ocenić czy to w ogóle ma sens.
> Ale co ma sens? Pakowanie danych jakiejś aplikacji do jednego pliku - myślę
> że ma sens, wygląda to bardziej elegancko niż do jednego katalogu. Czy
> jest sens pisania tego samemu od zera? Nie wiem, zależy jakie są gotowe
> rozwiązania, nie potrafię polecić żadnego gotowca.

Wolałbym gotowiec właśnie. W zasadzie to wolałbym tego w ogóle nie 
pisać, tylko skupić się na pozostałem częsci apliakcji.

Tak naprawdę, tam jest kilka innych zagadnień, których gotowce 
prawodpodobnie nie rozwiązują: np. defragmentacja w tle i powiązany z 
nim trim prawdziwego pliku.

On Sunday, February 7, 2021 at 8:57:46 PM UTC+1, heby wrote:
> On 07/02/2021 20:03, M.M. wrote: 
> >> 2) jak realizuej się wielodostep z wątków i locki w systemie. 
> > Z ciekawości zapytam, do czego potrzebujesz takiej wiedzy?
> Nie chcę 1 mutexa na wszystko. Wątków dostepowych będzie wiele. Skoro fs 
> są używane praktycznie wyłącznie w środowiskach wielowątkowych, to 
> przypuszczam że nie jest to jakaś specjalnie trudna sprawa. Znowu: mam 
> jakieś pomysły, ale pewnie naiwne. 

Nie pytałem ile chcesz mutexów. Nie wiem do czego tej wiedzy potrzebujesz. Jak tej 
wiedzy potrzebujesz do zaprojektowania procesora - to ja nie pomogę.  Mutex 
koncepcyjnie to prosta sprawa, jest gwarancja wykonania fragmentu kodu tak, 
jakby wykonywał go jeden wątek. Cechą specyficzna tego kodu jest zazwyczaj
zliczanie ile wątków przeszło przez jakąś barierę. Ale jaką techniką trzeba napylić 
tranzystory  aby to działało optymalnie - nie mam bladego pojęcia.


> Ba, zerknąłem w kod kilku fs, ale ciezko znaleźc jakieś anstrakcje, 
> zazwyczaj się silnie zoptymalizowane i struktura traci sie w 
> optymalizacjach.

Uroki optymalizacji... coś za coś.

> >> Na razie poszukuje inspiracji aby ocenić czy to w ogóle ma sens. 
> > Ale co ma sens? Pakowanie danych jakiejś aplikacji do jednego pliku - myślę 
> > że ma sens, wygląda to bardziej elegancko niż do jednego katalogu. Czy 
> > jest sens pisania tego samemu od zera? Nie wiem, zależy jakie są gotowe 
> > rozwiązania, nie potrafię polecić żadnego gotowca.
> Wolałbym gotowiec właśnie. W zasadzie to wolałbym tego w ogóle nie 
> pisać, tylko skupić się na pozostałem częsci apliakcji. 

> Tak naprawdę, tam jest kilka innych zagadnień, których gotowce 
> prawodpodobnie nie rozwiązują: np. defragmentacja w tle i powiązany z 
> nim trim prawdziwego pliku.

Jeśli dysponujemy dodatkowym miejsce to defragmentuje się łatwo: odczytuje
się kolejne pliki z jednego systemu i zapisuje do drugiego. Czasami warto 
zostawić trochę miejsca za plikiem do dopisania nowych danych... Bez konkretnego 
zastosowania trudno gdybać.

Pozdrawiam

On 07/02/2021 21:19, M.M. wrote:
> Nie pytałem ile chcesz mutexów. Nie wiem do czego tej wiedzy potrzebujesz. Jak tej
> wiedzy potrzebujesz do zaprojektowania procesora - to ja nie pomogę.

Nie projektuje procesora.

>  Mutex
> koncepcyjnie to prosta sprawa

Tu mutex powinien być na "fragment" filesystemu. Jestem prawie pewny, że 
w normalnym fs takie "mutexy" są powiązane z kroniką co czyni jest 
bardziej mechanizmem transakcyjnym niż prostym lockiem.

> zliczanie ile wątków przeszło przez jakąś barierę. Ale jaką techniką trzeba napylić
> tranzystory

No wiec nie napylam tanzystorów.

>> Tak naprawdę, tam jest kilka innych zagadnień, których gotowce
>> prawodpodobnie nie rozwiązują: np. defragmentacja w tle i powiązany z
>> nim trim prawdziwego pliku.
> Jeśli dysponujemy dodatkowym miejsce to defragmentuje się łatwo: odczytuje
> się kolejne pliki z jednego systemu i zapisuje do drugiego.

To jest naiwny algorytm. Wszystkie fs majace defragmentacje - robią ją w 
miejscu. Moe to zaprojektowc metodą garbage collectora z javy: stop the 
world. Ale coś czuje że to znowu naiwny algorytm.

On Sunday, February 7, 2021 at 10:01:21 PM UTC+1, heby wrote:
> On 07/02/2021 21:19, M.M. wrote: 
> > Nie pytałem ile chcesz mutexów. Nie wiem do czego tej wiedzy potrzebujesz. Jak tej 
> > wiedzy potrzebujesz do zaprojektowania procesora - to ja nie pomogę.
> Nie projektuje procesora. 

To dlaczego nie odpowiesz na pytanie: do czego potrzebujesz wiedzę o takich
szczegółach synchronizacji wątków?

> 
> > Mutex 
> > koncepcyjnie to prosta sprawa 
> 
> Tu mutex powinien być na "fragment" filesystemu. 

Tu czyli gdzie i dlaczego na fragment filesystemu? Co rozumiesz przez filesystem?

>Jestem prawie pewny, że 
> w normalnym fs takie "mutexy" są powiązane z kroniką co czyni jest 
> bardziej mechanizmem transakcyjnym niż prostym lockiem.

Transakcje nie są prostym lockiem, aczkolwiek z poziomu użytkownika to proste
wywołanie funkcji, np. w bazie danych komenda "begin" rozpoczyna transakcje. 
Transakcje umożliwiają naprawę tego co 'zaczęło' być modyfikowane.


> > zliczanie ile wątków przeszło przez jakąś barierę. Ale jaką techniką trzeba napylić 
> > tranzystory
> No wiec nie napylam tanzystorów.

Dlaczego więc chcesz wiedzieć jak wewnętrznie działają mutexy?


> >> Tak naprawdę, tam jest kilka innych zagadnień, których gotowce 
> >> prawodpodobnie nie rozwiązują: np. defragmentacja w tle i powiązany z 
> >> nim trim prawdziwego pliku. 
> > Jeśli dysponujemy dodatkowym miejsce to defragmentuje się łatwo: odczytuje 
> > się kolejne pliki z jednego systemu i zapisuje do drugiego.

> To jest naiwny algorytm. 
Naiwne algorytmy mają swoje zalety.

> Wszystkie fs majace defragmentacje - robią ją w 
> miejscu. Moe to zaprojektowc metodą garbage collectora z javy: stop the 
> world. Ale coś czuje że to znowu naiwny algorytm.

GC zlicza odnośniki do alokowanych obiektów, gdy jest zero, to może zwolnić.
Jaka jest optymalna struktura do takiego zliczania? Może jakieś drzewo 
zbalansowane i kolejka priorytetowa, a może naiwna liniowa tablica ma tak
mały narzut że to właśnie ją się najbardziej opłaca stosować dla typowych
aplikacji - nie wiem.

Pozdrawiam

On 07/02/2021 22:53, M.M. wrote:
> To dlaczego nie odpowiesz na pytanie: do czego potrzebujesz wiedzę o takich
> szczegółach synchronizacji wątków?

Ponieważ mutex w pamięci, dostarczany przez OS niekoniecznie jest tym 
samym co "mutex" na plik (lock) zapewniajacy spójnośc dnych podczas 
wielodostępu i defragmentacji w tle. Wymaga ręcznej implementacji, być 
moze opartej o mutexy OSowe, a może niekoniecznie, a może w ogóle są 
rozwiązania bez mutexa.

>>> koncepcyjnie to prosta sprawa
>> Tu mutex powinien być na "fragment" filesystemu.
> Tu czyli gdzie i dlaczego na fragment filesystemu? Co rozumiesz przez filesystem?

Na przykład na wirtualny plik w tym kontenerze.

Wyobraź sobie dwa wątki: jeden dopisuje coś do wirtualnego pliku, a 
drugi kasuje go.

Można to rozwiązać za pomocą inodes, jak w linuxie. Albo za pomocą 
mutexów "w filesystemie".

Oczywiście te "mutexy w filesystemie" to naiwny koncept. To mogą być 
zwykłe mutexy w implementacji filesystemu, ale raczej nie będą.

> Transakcje nie są prostym lockiem

Bo transakcja to kiepskie słowo. W zasadzie nie ma dobrego odpowiednika 
w DB zachowania filesystemu z kronikowaniem zapisywanego przez wiele wątków.

>>> zliczanie ile wątków przeszło przez jakąś barierę. Ale jaką techniką trzeba napylić
>>> tranzystory
>> No wiec nie napylam tanzystorów.
> Dlaczego więc chcesz wiedzieć jak wewnętrznie działają mutexy?

Nigdzie nie napisałem że chce wiedzieć jak działają *normalne* mutexy, 
bo to wiem. Interesuje mnie jak działa zapewnianie spójności danych w fs 
które dla usera wygląda jak typowy zasób krytyczny pilnowany przez mutex.

>> Wszystkie fs majace defragmentacje - robią ją w
>> miejscu. Moe to zaprojektowc metodą garbage collectora z javy: stop the
>> world. Ale coś czuje że to znowu naiwny algorytm.
> GC zlicza odnośniki do alokowanych obiektów, gdy jest zero, to może zwolnić.

Wiem, ale GC nie pojawił sie tutaj jako odpowiednik 1:1 tylko jao zły 
przykład "stop the world".

> Jaka jest optymalna struktura do takiego zliczania? Może jakieś drzewo
> zbalansowane i kolejka priorytetowa, a może naiwna liniowa tablica ma tak
> mały narzut że to właśnie ją się najbardziej opłaca stosować dla typowych
> aplikacji - nie wiem.

Potrzebuje literatury z teorii działania systemów plików. Wygdybać mogę 
sobie cokolwiek, ale konkuruje z dziesięcioleciami eksperymentów ludzi 
mądrzejszych ode mnie.

On Monday, February 8, 2021 at 7:39:33 AM UTC+1, heby wrote:
> On 07/02/2021 22:53, M.M. wrote: 
> > To dlaczego nie odpowiesz na pytanie: do czego potrzebujesz wiedzę o takich 
> > szczegółach synchronizacji wątków?

> Ponieważ mutex w pamięci, dostarczany przez OS niekoniecznie jest tym 
> samym co "mutex" na plik (lock) zapewniajacy spójnośc dnych podczas 
> wielodostępu i defragmentacji w tle. Wymaga ręcznej implementacji, być 
> moze opartej o mutexy OSowe, a może niekoniecznie, a może w ogóle są 
> rozwiązania bez mutexa.

Dane na których program pracuje to są dane, nie ma istotnego znaczenia
czy są one zapisane w pamięci RAM, na dysku talerzowym, na dysku SSD, 
na płycie CD, DVD, itd. Podobnie dane naprawcze to dane naprawcze, jeśli
są poprawne, to można dzieki nimi coś naprawić bez względu gdzie są
zapisane. Jedyna istotna różnica jest taka, że jak padnie system, to
też dochodzi do utraty danych w pamięci RAM i nie ma w niej nic do 
naprawiania. Dlatego w przypadku danych na pamięciach trwałych stosuje
się nie tylko mutexy, ale jeszcze przechowuje się dane naprawcze, które
(z tego co wiem zawsze) są w dzienniku zawierającym informacje o 
modyfikacjach.

Mutex sam w sobie nic nie zapewnia, spójność danych uzyskuje się
dzięki prawidłowmu użyciu mutexów i danych naprawczych. 


> >>> koncepcyjnie to prosta sprawa 
> >> Tu mutex powinien być na "fragment" filesystemu. 
> > Tu czyli gdzie i dlaczego na fragment filesystemu? Co rozumiesz przez filesystem?
> Na przykład na wirtualny plik w tym kontenerze. 
> 
> Wyobraź sobie dwa wątki: jeden dopisuje coś do wirtualnego pliku, a 
> drugi kasuje go. 

To jeszcze nic nie oznacza, może programista tak chciał? Ale generalnie
na tym właśnie polega problem: kilka wątków pracuje na tych samych
danych, zakładają że dane mają określoną wartość. Gdy jeden wątek dane
zmodyfikuje, to pozostałe już pracują na błędnym założeniu. Dlatego
robi się to co napisałem: jeśli jeden wątek zapisuje dane, to może
pracować tylko ten jeden wątek, ale do odczytu może być dowolnie wiele.
 
 
> Można to rozwiązać za pomocą inodes, jak w linuxie. Albo za pomocą 
> mutexów "w filesystemie". 
> 
> Oczywiście te "mutexy w filesystemie" to naiwny koncept. To mogą być 
> zwykłe mutexy w implementacji filesystemu, ale raczej nie będą. 
> 
> > Transakcje nie są prostym lockiem 
> 
> Bo transakcja to kiepskie słowo. W zasadzie nie ma dobrego odpowiednika 
> w DB zachowania filesystemu z kronikowaniem zapisywanego przez wiele wątków.

Też nie spotkałem się.


> >>> zliczanie ile wątków przeszło przez jakąś barierę. Ale jaką techniką trzeba napylić 
> >>> tranzystory 
> >> No wiec nie napylam tanzystorów. 
> > Dlaczego więc chcesz wiedzieć jak wewnętrznie działają mutexy?
> Nigdzie nie napisałem że chce wiedzieć jak działają *normalne* mutexy, 
> bo to wiem. Interesuje mnie jak działa zapewnianie spójności danych w fs 
> które dla usera wygląda jak typowy zasób krytyczny pilnowany przez mutex.

Ale kto powiedział że jest takie zapewnienie? Jeśli dwa wątki zaczną
czytać i pisać dane, to zepsują spójność danych w pliku, chyba że OS
nie pozwoli otworzyć pliku do zapisu gdy jest może to spowodować 
utratę spójnośći. OS powinien zapewniać tylko spójność struktury 
przechowującej dane na dysku, a robi sie to tak samo jak zawsze: mutexy 
i/albo dane naprawcze.


> >> Wszystkie fs majace defragmentacje - robią ją w 
> >> miejscu. Moe to zaprojektowc metodą garbage collectora z javy: stop the 
> >> world. Ale coś czuje że to znowu naiwny algorytm. 
> > GC zlicza odnośniki do alokowanych obiektów, gdy jest zero, to może zwolnić.

> Wiem, ale GC nie pojawił sie tutaj jako odpowiednik 1:1 tylko jao zły 
> przykład "stop the world".

Ok.

> > Jaka jest optymalna struktura do takiego zliczania? Może jakieś drzewo 
> > zbalansowane i kolejka priorytetowa, a może naiwna liniowa tablica ma tak 
> > mały narzut że to właśnie ją się najbardziej opłaca stosować dla typowych 
> > aplikacji - nie wiem.


> Potrzebuje literatury z teorii działania systemów plików. Wygdybać mogę 
> sobie cokolwiek, ale konkuruje z dziesięcioleciami eksperymentów ludzi 
> mądrzejszych ode mnie.

Może jest coś wartościowego?
https://www.google.com/search?channel=fs&client=ubuntu&q=systemy+plik%C3%B3w+literatura

Pozdrawiam

On 08/02/2021 11:08, M.M. wrote:
>> Wyobraź sobie dwa wątki: jeden dopisuje coś do wirtualnego pliku, a
>> drugi kasuje go.
> To jeszcze nic nie oznacza, może programista tak chciał?

To dopuszczalna sytuacja. fs ma być na nia gotowy.

> Ale generalnie
> na tym właśnie polega problem: kilka wątków pracuje na tych samych
> danych, zakładają że dane mają określoną wartość. Gdy jeden wątek dane
> zmodyfikuje, to pozostałe już pracują na błędnym założeniu. Dlatego
> robi się to co napisałem: jeśli jeden wątek zapisuje dane, to może
> pracować tylko ten jeden wątek, ale do odczytu może być dowolnie wiele.

Nieprawda. Jeśli jeden watek zapisuje jakas częśc pliku, inny może 
zapisuwać inną część tego samego pliku. DB często tak robią.

Granulacja jest więc dokładniejsza niż 1 plik. Co oznacza w naiwnym 
podejściu bardzo dużo muteksów na każdy kawałek pliku lub skomplikowany 
mutex z emulacją submutexów.

Przypuszcam że w ogóle sytuacja że zapisujemy ten sam kawałek pliku 
równolegle z dwóch wątków jest jak najbardziej dopuszczalna. Co najwyżej 
będzie race condition na dane, ale sam plik będzie dalej poprawny z 
punktu widzenia fs.

>> bo to wiem. Interesuje mnie jak działa zapewnianie spójności danych w fs
>> które dla usera wygląda jak typowy zasób krytyczny pilnowany przez mutex.
> Ale kto powiedział że jest takie zapewnienie?

W fs jest. Wątek A kasuje plik, wątek B czyta ten sam plik, wątek C 
właśnie go otwiera. I nie ma race conditions na poziomie fs, tam dane są 
spójne i stan jest atomowy.

> Jeśli dwa wątki zaczną
> czytać i pisać dane, to zepsują spójność danych w pliku, chyba że OS
> nie pozwoli otworzyć pliku do zapisu gdy jest może to spowodować
> utratę spójnośći.

To tak nie działa. POnadto rozróznijmy: race condition w aplikacji to 
coś innego niż race condition w fs. W tym drugim przypadku masz taką 
sytuację setki razy na sekundę w swoim PC.

>> Potrzebuje literatury z teorii działania systemów plików. Wygdybać mogę
>> sobie cokolwiek, ale konkuruje z dziesięcioleciami eksperymentów ludzi
>> mądrzejszych ode mnie.
> Może jest coś wartościowego?
> https://www.google.com/search?channel=fs&client=ubuntu&q=systemy+plik%C3%B3w+literatura

Obawiam się czy aby nie jest tylko od strony użytkowej. Ogólnie 
obejrzałem spisy kilkunastu książek z tego tematu i jak na razie nie 
widzę nic o budowie wewnętrznej. Być może coś przeoczyłem.

On Monday, February 8, 2021 at 12:12:29 PM UTC+1, heby wrote:
> On 08/02/2021 11:08, M.M. wrote: 
> >> Wyobraź sobie dwa wątki: jeden dopisuje coś do wirtualnego pliku, a 
> >> drugi kasuje go. 
> > To jeszcze nic nie oznacza, może programista tak chciał?
> To dopuszczalna sytuacja. fs ma być na nia gotowy.

Trudno sie rozmawia, nie wiem co dla Ciebie znaczy że FS
ma być gotowy. Skąd FS ma wiedzieć, czy to nie jest zaplanowane 
działanie programisty? Pracują np. dwa wątki. Jeden pisze do 
pliku, drugi kasuje plik. Jeśli jeden najpierw zapisze, a drugi
skasuje - to pliku nie będzie. Jeśli najpierw skasuje, a
potem dojdzie do próby zapisania, to też nie będzie pliku - fs
zwróci po prostu błąd zapisu. Niezbyt eleganckie rozwiązanie
ale zawsze zakończy się takim samym efektem. Chyba że gotowość
dla Ciebie oznacza to, że w takiej sytuacji całkowicie się
nie rozwali i nie dojdzie do utraty danych. To oczywiście że
powinien być w tym sensie gotowy, bo dane często zbiera się
długo i kosztownie, wiec trzeba bardzo dbać o dane.

Można zrobić taki rozwiązanie, że jak jeden wątek chce plik do 
zapisu, to FS czeka aż wszystkie inne wątki zamkną plik. A jak 
już jakiś wątek ma plik otwarty do zapisu, to FS nie pozwoli 
otworzyć pliku w żadnym trybie. Ale to wyklucza całkiem bezpieczną
sytuację, gdy N wątków pisze i czyta każdy do swojej SIZE/N
części. Po co sobie odbierać takie możliwości i to dodatkowym
nakładem pracy - ja nie wiem.


> > Ale generalnie 
> > na tym właśnie polega problem: kilka wątków pracuje na tych samych 
> > danych, zakładają że dane mają określoną wartość. Gdy jeden wątek dane 
> > zmodyfikuje, to pozostałe już pracują na błędnym założeniu. Dlatego 
> > robi się to co napisałem: jeśli jeden wątek zapisuje dane, to może 
> > pracować tylko ten jeden wątek, ale do odczytu może być dowolnie wiele.

> Nieprawda. Jeśli jeden watek zapisuje jakas częśc pliku, inny może 
> zapisuwać inną część tego samego pliku. DB często tak robią. 

Dlatego pisałem NA TYCH SAMYCH DANYCH, a INNE CZĘŚCI PLIKU to już
nie są TE SAME DANE.

> Granulacja jest więc dokładniejsza niż 1 plik. Co oznacza w naiwnym 
> podejściu bardzo dużo muteksów na każdy kawałek pliku lub skomplikowany 
> mutex z emulacją submutexów. 

Nie wiem... Dla mnie to brzmi trochę jak mieszanie rozwiązania szczegółowego z 
ogólnym. W szczegółowych zastosowaniach to programista wie które operacje
powinny być atomowe i uzyskuje taki efekt poprzez synchronizację wątków. 
Jak ogólnie uzyskać taki efekt? System by musiał dawać dostęp do zapisu lub
do odczytów poszczególnych zbiorów bitów. Użytkownik by musiał to zgłaszać
do systemu. A takie zgłaszanie jest tożsame z synchronizacją przy pomocy
mutexów... 

Są jeszcze transakcje, wszystkie wątki próbują czytać i pisać do wszystkiego, a
system sprawdza czy transakcje nie kolidują ze sobą. Jeśli któryś wątek otrzyma
od systemu informację o kolizji, to musi wznowić swoje działanie z uwzględnieniem
tego, że ostatnia transakcja się nie udała - innymi słowy, aplikacja musi być
przygotowana na możliwość nie powodzenia się transakcji. W minimalnej wersji
chociaż musi się wywalić i użytkownik musi ją wznowić.
 
> Przypuszcam że w ogóle sytuacja że zapisujemy ten sam kawałek pliku 
> równolegle z dwóch wątków jest jak najbardziej dopuszczalna. Co najwyżej 
> będzie race condition na dane, ale sam plik będzie dalej poprawny z 
> punktu widzenia fs.

To brzmi sensownie! Jak programista nie zrobił poprawnie synchronizacji
wątków to jego problem.

> >> bo to wiem. Interesuje mnie jak działa zapewnianie spójności danych w fs 
> >> które dla usera wygląda jak typowy zasób krytyczny pilnowany przez mutex. 
> > Ale kto powiedział że jest takie zapewnienie?

> W fs jest. Wątek A kasuje plik, wątek B czyta ten sam plik, wątek C 
> właśnie go otwiera. I nie ma race conditions na poziomie fs, tam dane są 
> spójne i stan jest atomowy.

No tak, głupio byłoby, gdyby z powodu złej synchronizacji wątków rozleciał
się system plików. A czy dane w plikach są poprawne/spójne czy nie - to już 
zależy od poprawności aplikacji.


> > Jeśli dwa wątki zaczną 
> > czytać i pisać dane, to zepsują spójność danych w pliku, chyba że OS 
> > nie pozwoli otworzyć pliku do zapisu gdy jest może to spowodować 
> > utratę spójnośći.
> To tak nie działa. POnadto rozróznijmy: race condition w aplikacji to 
> coś innego niż race condition w fs. W tym drugim przypadku masz taką 
> sytuację setki razy na sekundę w swoim PC.
> >> Potrzebuje literatury z teorii działania systemów plików. Wygdybać mogę 
> >> sobie cokolwiek, ale konkuruje z dziesięcioleciami eksperymentów ludzi 
> >> mądrzejszych ode mnie. 
> > Może jest coś wartościowego? 
> > https://www.google.com/search?channel=fs&client=ubuntu&q=systemy+plik%C3%B3w+literatura

> Obawiam się czy aby nie jest tylko od strony użytkowej. Ogólnie 
> obejrzałem spisy kilkunastu książek z tego tematu i jak na razie nie 
> widzę nic o budowie wewnętrznej. Być może coś przeoczyłem.

Nie wiem jaka jest budowa wewnętrzna, ale mi się mocno narzuca to
co już pisałem: zwykła komórka pamięci do której w jednej chwili
ma dostęp do jeden wątek.

A budowa wewnętrzna dzienników to jest po prostu spis operacji i
kopia danych które w razie usterki będzie trzeba odtworzyć.

Pozdrawiam

On 08/02/2021 14:24, M.M. wrote:
>> To dopuszczalna sytuacja. fs ma być na nia gotowy.
> Trudno sie rozmawia, nie wiem co dla Ciebie znaczy że FS
> ma być gotowy. Skąd FS ma wiedzieć, czy to nie jest zaplanowane
> działanie programisty?

Ma nie wiedzieć. Jedyne co od niego oczekuje to to że nie rozwali sobie 
wewnętrznych struktur kiedy dwa wątki będą starały się jednoczesnie 
powiekszyć długość pliku albo skasować go w tym samym momencie.

> Pracują np. dwa wątki. Jeden pisze do
> pliku, drugi kasuje plik. Jeśli jeden najpierw zapisze, a drugi
> skasuje - to pliku nie będzie. Jeśli najpierw skasuje, a
> potem dojdzie do próby zapisania, to też nie będzie pliku - fs
> zwróci po prostu błąd zapisu.

Super. Tego właśnie oczekuje. Ma się nie rozsypać. To że w danych jest 
sieczka, to problem aplikacji, nie fs.

> Można zrobić taki rozwiązanie, że jak jeden wątek chce plik do
> zapisu, to FS czeka aż wszystkie inne wątki zamkną plik.

O nie.

>> Nieprawda. Jeśli jeden watek zapisuje jakas częśc pliku, inny może
>> zapisuwać inną część tego samego pliku. DB często tak robią.
> Dlatego pisałem NA TYCH SAMYCH DANYCH, a INNE CZĘŚCI PLIKU to już
> nie są TE SAME DANE.

To żadna róznica. fs nie obchodzi co i gdzie zapisuje. Jeśli ktoś 
zapisuje te same dane pikoseundę później to nie jest problem fs.

> Nie wiem... Dla mnie to brzmi trochę jak mieszanie rozwiązania szczegółowego z
> ogólnym. W szczegółowych zastosowaniach to programista wie które operacje
> powinny być atomowe i uzyskuje taki efekt poprzez synchronizację wątków.

Nie rozmawiamy tutaj o kliencie tego fs. W nim ta wiedza istnieje.

W fs nie ma żadnej wiedzy o atomowości operacji na plikach. Jedyne co 
wymagam od niego to fakt że "open" zadziała atomowo, "close" zadziała 
atomowo, "rm" itd. Ma pozwolić na 2x write jednocześnie w to samo 
miejsce i się nie rozlecieć.

> A budowa wewnętrzna dzienników to jest po prostu spis operacji i
> kopia danych które w razie usterki będzie trzeba odtworzyć.

To zdecydownie nie wygląda tak prosto w kodzie ext4...

On Monday, February 8, 2021 at 2:57:15 PM UTC+1, heby wrote:
> On 08/02/2021 14:24, M.M. wrote: 
> >> To dopuszczalna sytuacja. fs ma być na nia gotowy. 
> > Trudno sie rozmawia, nie wiem co dla Ciebie znaczy że FS 
> > ma być gotowy. Skąd FS ma wiedzieć, czy to nie jest zaplanowane 
> > działanie programisty?

> Ma nie wiedzieć. Jedyne co od niego oczekuje to to że nie rozwali sobie 
> wewnętrznych struktur kiedy dwa wątki będą starały się jednoczesnie 
> powiekszyć długość pliku albo skasować go w tym samym momencie.

I chcesz żeby ktoś podpowiedział Ci rozwiązanie jak to wydajnie
zrobić żebyś mógł konkurować z 50letnim doświadczeniem projektantów
systemów plików ;-) To ja się nie odważę pomagać. Ale jakbyś 
chciał pierwsze lepsze rozwiązanie, to bym się odważył podpowiedzieć,
że można zrobić koleję zadań. Zadania do kolejki będą dodawawane 
przez aplikacje klienckie. Natomiast system plików z kolejki w N
wątkach będzie pobierał zadania. Jednakże, jeśli jeden wątek 
otrzyma zadanie file_1, dotyczące pliku 'file' i w kolejce pojawi
się zadanie file_2, dotyczące tego samego pliku 'file', to algorytm
XYZ będzie musiał zdecydować, czy zadanie jest krytyczne dla bezpieczeństwa
struktury danych, czy też nie. Jeśli nie, to będzie musiał czekać
aż wątek obsługujący zadanie file_1 zakończy działanie i dopiero
potem przydzielić zadanie file_2. Algorytm XYZ wymaga zastanowienia...
W najprostszej wersji zapis do jednego pliku można robić równolegle,
bo aplikacja kliencka powinna zadbać o to, aby zapisy były bezpieczne.
Podobnie odczty można robić w wielu wątkach. Natomiast odczyt musi
czekać aż wszystkie zapisy się zakończą. Zapis też musi czekać aż
wszystkie odczyty się zakończą. Potem wyjątek, jeśli zapis i odczyt
pochodzi z różnych procesów/wątków, to może być zrównoleglany, bo o to
aplikacja kliencka już powinna zadbać. A zmiana rozmiaru plików...
nie wiem... chyba powinna być traktowana jako zapis. 

Dodam, nie polegaj szczególnie na tym, wymyśliłem to w chwili
pisania tego posta, nigdy nic nie czytałem o systemach plików.
Poza tym to jest bardzo ogólnikowe, w praktyce dojdzie pierdylion 
szczegółów.



> > Pracują np. dwa wątki. Jeden pisze do 
> > pliku, drugi kasuje plik. Jeśli jeden najpierw zapisze, a drugi 
> > skasuje - to pliku nie będzie. Jeśli najpierw skasuje, a 
> > potem dojdzie do próby zapisania, to też nie będzie pliku - fs 
> > zwróci po prostu błąd zapisu.

> Super. Tego właśnie oczekuje. Ma się nie rozsypać. To że w danych jest 
> sieczka, to problem aplikacji, nie fs.

Jeśli chesz to implementować pod konkretne zastosowanie, to może
się też rozwalić FS, bo będziesz wiedział że dana kombinacja 
operacji nigdy nie nastąpi i w praktyce jednak się nie rozwali.

> > Można zrobić taki rozwiązanie, że jak jeden wątek chce plik do 
> > zapisu, to FS czeka aż wszystkie inne wątki zamkną plik.

> O nie.

Przydatność zależy od konkretnego zastosowania. 



> >> Nieprawda. Jeśli jeden watek zapisuje jakas częśc pliku, inny może 
> >> zapisuwać inną część tego samego pliku. DB często tak robią. 
> > Dlatego pisałem NA TYCH SAMYCH DANYCH, a INNE CZĘŚCI PLIKU to już 
> > nie są TE SAME DANE.
> To żadna róznica. fs nie obchodzi co i gdzie zapisuje. Jeśli ktoś 
> zapisuje te same dane pikoseundę później to nie jest problem fs.
> > Nie wiem... Dla mnie to brzmi trochę jak mieszanie rozwiązania szczegółowego z 
> > ogólnym. W szczegółowych zastosowaniach to programista wie które operacje 
> > powinny być atomowe i uzyskuje taki efekt poprzez synchronizację wątków.
> Nie rozmawiamy tutaj o kliencie tego fs. W nim ta wiedza istnieje. 

Zaczęliśmy rozmowę od tego, że głupio gdy aplikacja zapisuje dane w
katalogu a nie w pliku, więc zahaczaliśmy też mocno o klienta.


 
> W fs nie ma żadnej wiedzy o atomowości operacji na plikach. 

Ale Ty chcesz pisać swój, bardzo specyficzny, zoptymalizowany 
pod konkretną aplikację - tak zrozumiałem.


> Jedyne co 
> wymagam od niego to fakt że "open" zadziała atomowo, "close" zadziała 
> atomowo, "rm" itd. Ma pozwolić na 2x write jednocześnie w to samo 
> miejsce i się nie rozlecieć.

To w pierwszym akapicie tego posta dałem zarys synchronizacji, a 
chyba w pierwszym poscie zaproponowałem strukturę danych (tam
gdzie byłą lista list, nagłówek pliku, nagłówki miejsca pustego,
zajętego, itd.) Nic bardziej szczegółowego w trakcie luźnej 
rozmowy nie podpowiem. 


> > A budowa wewnętrzna dzienników to jest po prostu spis operacji i 
> > kopia danych które w razie usterki będzie trzeba odtworzyć.

> To zdecydownie nie wygląda tak prosto w kodzie ext4...

Bo, jak się domyślam, są mocno zoptymalizowane i mają pierdylion
opcji dobieranych w (auto)tuningu i mogą się dostosować do 
wielu urządzeń. 


Pozdrawiam
 

On 08/02/2021 18:35, M.M. wrote:
> I chcesz żeby ktoś podpowiedział Ci rozwiązanie

Nie, aby wskazał gdzie szukać. Wydaje mi się że wiele lat temu migneła 
mi ksiązka w tym temacie, anglojezyczna. Nie pamietam tytułu, opisywała 
na pewno FAT i jeszcze coś, pod kątem detali implementacji. Miałem w 
ręku i tyle ją widziałem.

>> W fs nie ma żadnej wiedzy o atomowości operacji na plikach.
> Ale Ty chcesz pisać swój, bardzo specyficzny, zoptymalizowany
> pod konkretną aplikację - tak zrozumiałem.

To że coś jest embedowalne, nie oznacza że nie ma być abstrakcyjne. Ma 
być. FS ma nie mieć wiedzy o sposobie uzycia, ma byc odporny na dziwne 
uzycie.

On Monday, February 8, 2021 at 6:41:48 PM UTC+1, heby wrote:
> On 08/02/2021 18:35, M.M. wrote: 
> > I chcesz żeby ktoś podpowiedział Ci rozwiązanie
> Nie, aby wskazał gdzie szukać. Wydaje mi się że wiele lat temu migneła 
> mi ksiązka w tym temacie, anglojezyczna. Nie pamietam tytułu, opisywała 
> na pewno FAT i jeszcze coś, pod kątem detali implementacji. Miałem w 
> ręku i tyle ją widziałem.
> >> W fs nie ma żadnej wiedzy o atomowości operacji na plikach. 
> > Ale Ty chcesz pisać swój, bardzo specyficzny, zoptymalizowany 
> > pod konkretną aplikację - tak zrozumiałem.
> To że coś jest embedowalne, nie oznacza że nie ma być abstrakcyjne. Ma 
> być. FS ma nie mieć wiedzy o sposobie uzycia, ma byc odporny na dziwne 
> uzycie.

Gdzie szukać - nie wiem. To co mi zdrowy rozsądek podpowiedział w przeciągu 
kilku postów i 30 minut zastanowienia - napisałem.  Więcej pomóc nie potrafię,
sam bym musiał poczytać, ale do czytania nie mam motywacji w świecie pełnym 
Sqlite, PostgreSQL, MongoDB, BDB, Redis i czego tam jeszcze; o gotowych systemach 
plików nie wspomniawszy. 

Ja może bym chciał poczytać książkę o optymalizacji powyższych baz danych z 
uwzględnieniem nowoczesnych dysków SSD na złączu M.2, dysków RAM, macierzy 
dyskowych i to wszystko w połączeniu z doborem rodzaju i parametrów systemu plików. 

Pozdrawiam

W dniu 2021-02-08 o 18:41, heby pisze:
> On 08/02/2021 18:35, M.M. wrote:
>> I chcesz żeby ktoś podpowiedział Ci rozwiązanie
> 
> Nie, aby wskazał gdzie szukać. Wydaje mi się że wiele lat temu migneła 
> mi ksiązka w tym temacie, anglojezyczna. Nie pamietam tytułu, opisywała 
> na pewno FAT i jeszcze coś, pod kątem detali implementacji. Miałem w 
> ręku i tyle ją widziałem.

Trochę stara, ale może ta byłaby odpowiednia:
Dominic Giampaolo „Practical File System Design”, Morgan Kaufmann 1999
Autor omawia system plików BFS z BeOS.
Do znalezienia w necie, Google wyrzuca pdf-a jako pierwszy wynik w 
wyszukiwaniu...

Poza tym można szukać w książkach o systemach operacyjnych, np.:

Tanenbaum, Woodhull „Operating Systems Design and Implementation”, 3rd 
ed, to jest o implementacji systemu MINIX, jest ponad 100 stron o 
systemie plików + kod źródłowy.

Tannenbaum „Modern Operating Systems”, jest 70 stron o systemach plików.

Silberschatz „Operating System Concepts”, 9th ed, 2012 jest ponad 150 
stron o „storage management”, w tym podrozdział „file system 
implementation” 40 stron.

Remzi, Arpaci-Dusseau „Operating Systems Three Easy Pieces”, rozdział 
„persistence” ma ponad 150 stron.

Ciekawe rzeczy można też znaleźć w książkach o implementacji baz danych, 
w końcu plik bazy danych ze zbiorem rekordów i indeksem nie różni się w 
swojej istocie zbytnio od systemu plików.

Są też z wydawnictwa O'Reilly (widziałem tylko tytuły, nie przeglądałem):
Rajeev Nagar „Windows NT File System Internals: A Developer's Guide”
Stan Mitchell „Inside the Windows 95 file system”

On 08/02/2021 20:33, Piotr Chamera wrote:
> [ciach]

Dzieki.

W dniu 2021.01.14 o 13:31, heby pisze:
> Cześć.
> 
> Coś w ten deseń, czyli to ja dostaczam abstrakcje robiącą I/O na 
> poziomie block/cluster a kod realizuje wysokopoziomowe operacje plikowe.
> 

Ty musisz napisać własny format pliku. Tylko tyle i aż tyle. System 
plików to zupełnie inna para butów.

Nie wiem w czym to docelowo będziesz pisał ale do tej operacji wystarczy 
Ci znajomość Strumieni i przemyślany sposób jak to upakować wszystko.

Dla uproszczenia zrób sobie każdy element pliku (Formatu pliku) w 
oddzielnej klasie będzie ci łatwiej okiełznać strukturę w późniejszym 
etapie przy takim podejściu

Pozdrawiam
J-23

On 05/04/2021 03:51, J-23 wrote:
>> Coś w ten deseń, czyli to ja dostaczam abstrakcje robiącą I/O na 
>> poziomie block/cluster a kod realizuje wysokopoziomowe operacje plikowe.
> Ty musisz napisać własny format pliku.

Dziekuję, to odkrywcze :D

> Tylko tyle i aż tyle. System 
> plików to zupełnie inna para butów.

A ja myślałem że tam jest cała esencja.

> Nie wiem w czym to docelowo będziesz pisał ale do tej operacji wystarczy 
> Ci znajomość Strumieni i przemyślany sposób jak to upakować wszystko.

O to przemyślenie chodzi. Strumienie ogarniam. Ba, ograniam nawet random 
access.

> Dla uproszczenia zrób sobie każdy element pliku (Formatu pliku) w 
> oddzielnej klasie będzie ci łatwiej okiełznać strukturę w późniejszym 
> etapie przy takim podejściu

Genialne.

Jesteś pewny że wiesz o czym mówisz ;) ?

W dniu 2021.04.05 o 11:30, heby pisze:
> Jesteś pewny że wiesz o czym mówisz ;) ?

Widać po twoich postach w tym wątku że próbujesz robić pewne rzeczy do 
okola pytanie po co? Moim zdaniem sięgasz zbyt głęboko. To co opisujesz 
według mnie da się prosto.

Słowa typu "ogarniam nawet random access" jest nieudaną próbą szyderstwa 
z Twojej strony z tego co napisałem bo coś chcesz stworzyć ale sam do 
końca nie wiesz co to ma być ale napewno nie będzie to nawet "wirtualny 
filesystem" jak to sam nazwałeś

Chcesz budować Filesystem to pochwal się jak masz to ogarnięte do tej 
pory lub podejrzyj jak to jest budowane np w kodzie open source 
przykładów w sieci jest sporo.

Popraw mnie jeśli się myle ale twoja próbka kodu ma za zadanie (posłużę 
się twoim nazewnictwem)

1. Utworzyć FileSystem
2. Zapisać jakieś dane
3. Wysłać do urządzenia

Tylko pytanie po co?

Niby coś tam wyjaśniasz niżej ale ja nadal nie widzę po tych 
wyjaśnieniach powodu budowania własnego Filesystem

Zamiast wykorzystać już jakieś gotowe rozwiązanie

W tym co starasz się zbudować widzę sens grzebania w postaci nauki jak 
działają Systemy plików skoro to jest twoim celem to ok

Ale jeśli twoim celem jest budowanie systemu plików by upakować kilka 
plików w jedną strukturę jest pozbawione sensu bo to obecne systemy 
plików robią bez problemu

Pozdrawiam
J-23

On 05/04/2021 20:27, J-23 wrote:
>> Jesteś pewny że wiesz o czym mówisz ;) ?
> Widać po twoich postach w tym wątku że próbujesz robić pewne rzeczy do 
> okola

Tak, nie jest do zdecydowanie następna apliakcja do fakturowania.

> pytanie po co?

Zostało to wyjaśnione.

> Moim zdaniem sięgasz zbyt głęboko. To co opisujesz 
> według mnie da się prosto.

Więc jak?

> Słowa typu "ogarniam nawet random access"

Nie, to jest zwrócenie uwagi że "strumieniami" tego się nie ogarnia. To 
się ogarnia random access na rzeczywistym pliku. Razem z trim i kilkoma 
sztuczkami jak garbage collecting czy kompaktacja.

> z Twojej strony z tego co napisałem bo coś chcesz stworzyć ale sam do 
> końca nie wiesz co

*DOSKONALE* wiem co.

> to ma być ale napewno nie będzie to nawet "wirtualny 
> filesystem" jak to sam nazwałeś

Możesz się podeprzeć jakimś powodem, dlaczego to nie będzie wirtualny 
filesystem?

> Chcesz budować Filesystem to pochwal się jak masz to ogarnięte do tej 
> pory

Poczytaj wątek. Mam możliwosć schowania tego za abstrackją i aktualnie 
używam database. Ale database jest marną emulacją.

> lub podejrzyj jak to jest budowane np w kodzie open source 
> przykładów w sieci jest sporo.

Bardzo dobra rada. Problem w tym, że kod do większości filesystemów jest 
przesadnie zagmatwany aby można było wyłuskać z niego sensowne 
abstrakcje. A wiele oglądałem. Najzwyczajniej, produkcyjne filesystemy 
są optymalizowane a nie pisane po to aby je podziwiać.

> Popraw mnie jeśli się myle ale twoja próbka kodu ma za zadanie (posłużę 
> się twoim nazewnictwem)
> 1. Utworzyć FileSystem
> 2. Zapisać jakieś dane
> 3. Wysłać do urządzenia

Nie.

Ma pracować na 1 pliku, a w środku ma pozwalać na operowanie nieznaną 
iloscią plikó wirtualnych, dynamicznie je tworząc, kasując, 
powiększając, nadpisując. Mniej więcej to co robi normalny filesystem na 
normalnym dysku.

Mała uwaga: to nie to samo co zamontowanie ext4 na loop. To ma być 
dynamicznie zmieniające rozmiar pliku rzeczywistego.

Najbliższy koncept z tej okolicy to np. qcow2.

> Tylko pytanie po co?

Odpowiedź padła w tym wątku.

> Niby coś tam wyjaśniasz niżej ale ja nadal nie widzę po tych 
> wyjaśnieniach powodu budowania własnego Filesystem

Bo nie przeczytałeś uważnie.

> Zamiast wykorzystać już jakieś gotowe rozwiązanie

Zasugeruj jakie. Nie znajduje gotowych rozwiązań poza workaroudami jak 
bloby w db.

> Ale jeśli twoim celem jest budowanie systemu plików by upakować kilka 
> plików w jedną strukturę jest pozbawione sensu bo to obecne systemy 
> plików robią bez problemu

Interesujące, podrzuć jakiś filesystem który pakuje pliki do jednego 
pliku i pozwala na ich dynamiczne używanie jednoczesnie kompaktując plik 
fizyczny.

W dniu 2021.04.05 o 23:04, heby pisze:
> On 05/04/2021 20:27, J-23 wrote:
>>> Jesteś pewny że wiesz o czym mówisz ;) ?
>> Widać po twoich postach w tym wątku że próbujesz robić pewne rzeczy do 
>> okola
> 
> Tak, nie jest do zdecydowanie następna apliakcja do fakturowania.

Aplikacje do fakturowania są proste a i tak większość działa w "dziwny" 
sposób bo co program to inne podejście :)
> 
>> pytanie po co?
> 
> Zostało to wyjaśnione.

Nie zostało to jednoznacznie wyjaśnione nawet osoba która dużo 
dyskutowała z Tobą w tym wątku stwierdziła że cieżko się rozmawia bo nie 
odpowiadasz na pytania
> 
>> Moim zdaniem sięgasz zbyt głęboko. To co opisujesz według mnie da się 
>> prosto.
> 
> Więc jak?
> 

Możesz to zrobić na co najmniej dwa sposoby
1. Korzystając ze strumieni i pliku binarnego
2. Wykorzystując formaty tj VDI

https://www.arysontechnologies.com/blog/how-to-open-vdi-file/#:~:text=VDI%20or%20Virtual%20Drive%20Format,Windows%20and%20other%20operating%20systems.

wiele innych jest tego sporo tylko ta opcja druga jest moim zdaniem w 
Twoim przypadku na "wyrost"

Dostęp do źrodeł masz opisy formatu znajdziesz też w sieci

>> Słowa typu "ogarniam nawet random access"
> 
> Nie, to jest zwrócenie uwagi że "strumieniami" tego się nie ogarnia. To 
> się ogarnia random access na rzeczywistym pliku. Razem z trim i kilkoma 
> sztuczkami jak garbage collecting czy kompaktacja.
> 
>> z Twojej strony z tego co napisałem bo coś chcesz stworzyć ale sam do 
>> końca nie wiesz co
> 
> *DOSKONALE* wiem co.


Bez szyderstwa. Napisz więcej co to ma robić bo mam wrażenie że 
strzelasz z armaty do wróbla

> 
>> to ma być ale napewno nie będzie to nawet "wirtualny filesystem" jak 
>> to sam nazwałeś
> 
> Możesz się podeprzeć jakimś powodem, dlaczego to nie będzie wirtualny 
> filesystem?
> 
>> Chcesz budować Filesystem to pochwal się jak masz to ogarnięte do tej 
>> pory

Bo to co chcesz zbudować jest formatem pliku emulującym działanie 
systemu plików a to różnica

Napisałem już w pierwszym moim poście że musisz zbudować odpowiedni 
format pliku

Nawet przywołane przeze mnie VDI jest formatem pliku a nie systemem plików

> 
> Poczytaj wątek. Mam możliwosć schowania tego za abstrackją i aktualnie 
> używam database. Ale database jest marną emulacją.
> 

Po co ci Database? Armata na wróbla chociaż podejrzewam że będzie i tak 
bardziej wydajna niż to co stworzysz przynajmniej w pierwszych wersjach

>> lub podejrzyj jak to jest budowane np w kodzie open source przykładów 
>> w sieci jest sporo.
> 
> Bardzo dobra rada. Problem w tym, że kod do większości filesystemów jest 
> przesadnie zagmatwany aby można było wyłuskać z niego sensowne 
> abstrakcje. A wiele oglądałem. Najzwyczajniej, produkcyjne filesystemy 
> są optymalizowane a nie pisane po to aby je podziwiać.
> 

Teraz jak wiem o co ci chodzi to odpowiem tak. Przejrzyj formaty które 
to umożliwiają przechowywać obraz dysku np wspomniany przeze mnie VDI bo 
System plików będzie faktycznie mocno zagmatwany bo ty potrzebujesz 20% 
tego co w systemie plików jest zawarte

>> Popraw mnie jeśli się myle ale twoja próbka kodu ma za zadanie 
>> (posłużę się twoim nazewnictwem)
>> 1. Utworzyć FileSystem
>> 2. Zapisać jakieś dane
>> 3. Wysłać do urządzenia
> 
> Nie.
> 
> Ma pracować na 1 pliku, a w środku ma pozwalać na operowanie nieznaną 
> iloscią plikó wirtualnych, dynamicznie je tworząc, kasując, 
> powiększając, nadpisując. Mniej więcej to co robi normalny filesystem na 
> normalnym dysku.

Kluczowe pytanie do czego ci to potrzebne bo nadal przy tej "dawce 
wiedzy" będę sie upierał że wystarczą ci strumienie by to napisać

Strumienie nie dadzą rady w momencie gdy potrzebujesz z tego wycisnąć 
max wydajności

> 
> Mała uwaga: to nie to samo co zamontowanie ext4 na loop. To ma być 
> dynamicznie zmieniające rozmiar pliku rzeczywistego.
> 
> Najbliższy koncept z tej okolicy to np. qcow2.

https://formats.kaitai.io/vdi/java.html
> 
>> Tylko pytanie po co?
> 
> Odpowiedź padła w tym wątku.
> 

Dopiero teraz :)

>> Niby coś tam wyjaśniasz niżej ale ja nadal nie widzę po tych 
>> wyjaśnieniach powodu budowania własnego Filesystem
> 
> Bo nie przeczytałeś uważnie.

Przeczytałem tylko dopiero w odpowiedzi do mnie napisałeś to w jasny 
sposób ale nie ma o co się spierać
> 
>> Zamiast wykorzystać już jakieś gotowe rozwiązanie
> 
> Zasugeruj jakie. Nie znajduje gotowych rozwiązań poza workaroudami jak 
> bloby w db.
> 


Zasugerowałem format VDI lub zbuduj własny format co nie jest takie 
trudne jak zglebisz temat formatu plików pozwalający przechowywać obraz 
dysku.

Moim zdaniem błędnie się zasugerowałeś że to ma być FileSystem

>> Ale jeśli twoim celem jest budowanie systemu plików by upakować kilka 
>> plików w jedną strukturę jest pozbawione sensu bo to obecne systemy 
>> plików robią bez problemu
> 
> Interesujące, podrzuć jakiś filesystem który pakuje pliki do jednego 
> pliku i pozwala na ich dynamiczne używanie jednoczesnie kompaktując plik 
> fizyczny.

wspomniany tu przeze mnie VDI to robi ale mam wrażenie że ty i tak tego 
nie potrzebujesz.

Moja rada poczytaj o tym jak się konstruję formaty plików i odejść od 
myślenia (na tym etapie) od tego że to jest system plików

Pytanie czy da się strumieniami twoim zdaniem zapakować kilka plików do 
jednego pliku?

Zadaje to pytanie nie po by się z Ciebie nabijać tylko po to by 
zrozumieć czemu sądzisz ze pliki typu qcow2/vdi są systemami plików.



Pozdrawiam
J-23

W dniu 2021.04.05 o 23:04, heby pisze:
>> Słowa typu "ogarniam nawet random access"
> 
> Nie, to jest zwrócenie uwagi że "strumieniami" tego się nie ogarnia. To 
> się ogarnia random access na rzeczywistym pliku. Razem z trim i kilkoma 
> sztuczkami jak garbage collecting czy kompaktacja.


Zapomniałem się odnieść do tego co wyżej. To zdziwisz się czym to jest 
ogarnięte np w VirtualBox.

Mieszasz pojęcia nie rozumiesz co to jest format pliku. Mylisz go z 
systemem pliku nawet mam wrażenie że nie ogarniasz tego co twierdzisz ze 
ogarniasz

1. Random access - masz na myśli losowy dostęp? No i nie ma on nic 
wspolnego ze strumeniami tak?

2. Trim - to nawet pozostawie bez komentarza

3. Gerbage Collector że tak zapytam co ma wspólnego z system plikow - 
nic. Ma do czynienia z zarządzaniem pamięcią a zarządzanie pamięcią a 
system plików to dwa odrębne tematy

Pozdrawiam
J-23

On 05/04/2021 23:55, J-23 wrote:
>> Zostało to wyjaśnione.
> Nie zostało

Więc jeszcze raz: chciałbym kilka plików, któe generuje apliakcja, 
zawszeć w jednym. W przewieństwie do pakowania a'la zip, to ma być 
dostepne jak normalne pliki, czyli mogę do niczh coś dopisać, trimować, 
tworzyć i kasować.

Unikam wtedy bałaganu w postaci katalogu z plikami, w których user może 
coś uszkodzić. Praktyka pokazała że to *krytyczne*.

>> Więc jak?
> Możesz to zrobić na co najmniej dwa sposoby
> 1. Korzystając ze strumieni i pliku binarnego

Omijasz podstawowy problem. Strukturę tego pliki "binarnego". Skupiasz 
się na trzecirzędnych duprelach.

> 2. Wykorzystując formaty tj VDI
> https://www.arysontechnologies.com/blog/how-to-open-vdi-file/#:~:text=VDI%20or%20Virtual%20Drive%20Format,Windows%20and%20other%20operating%20systems. 

To bardzo milutkie, ale to tylko 1/10 sukcesu. Co z filesystemem? Mam 
sobie skombinować skądś ext4 w wersji bez kernela?

> Dostęp do źrodeł masz opisy formatu znajdziesz też w sieci

Ale to nie jest format zapisu plików, tylko format zapisu *dysku*. 
Brakuje tej warstwy o której mowa w temacie.

>> *DOSKONALE* wiem co.
> Bez szyderstwa. Napisz więcej co to ma robić bo mam wrażenie że 
> strzelasz z armaty do wróbla

Napisałem wyżej.

>>> Chcesz budować Filesystem to pochwal się jak masz to ogarnięte do tej 
>>> pory
> Bo to co chcesz zbudować jest formatem pliku emulującym działanie 
> systemu plików a to różnica

Nie, to nie jest róznica, dokładnie to chce uzyskać od samego początku.

> Napisałem już w pierwszym moim poście że musisz zbudować odpowiedni 
> format pliku

Świetnie:

Pacjet: Panie doktorze co dalej?
Doktur: Powinien pan wyzdrowieć, od tego proszę zacząć.

> Nawet przywołane przeze mnie VDI jest formatem pliku a nie systemem plików

No własnie, dlatego jest poza tematem. Ogólnie jeśli mam już bloki, to 
abstrakcja zapisująca je do pliku jest mało istotną duperelą. Skupiasz 
się na nieistotnym technicznie detalu.

>> Poczytaj wątek. Mam możliwosć schowania tego za abstrackją i aktualnie 
>> używam database. Ale database jest marną emulacją.
> Po co ci Database?

Aby emulować filesystem w pliku na potrzeby unit testów.

>> Bardzo dobra rada. Problem w tym, że kod do większości filesystemów 
>> jest przesadnie zagmatwany aby można było wyłuskać z niego sensowne 
>> abstrakcje. A wiele oglądałem. Najzwyczajniej, produkcyjne filesystemy 
>> są optymalizowane a nie pisane po to aby je podziwiać.
> Teraz jak wiem o co ci chodzi to odpowiem tak. Przejrzyj formaty które 
> to umożliwiają przechowywać obraz dysku np wspomniany przeze mnie VDI

Formaty maszyn wirtualnych służa tylko do tego aby gołe sektory trzymać 
w jakiś mniej-wiecej optymalny sposób w jednym pliku.

Niejak nie pomagają mi w wyższej warstwie abstrackji typu "jak trzymać 
pliki w tym pliku".

> bo 
> System plików będzie faktycznie mocno zagmatwany bo ty potrzebujesz 20% 
> tego co w systemie plików jest zawarte

Raczej 80%. Poza katalogami i atrybutami, ale oba to chyba jakieś mało 
istotne rzeczy.

>> Ma pracować na 1 pliku, a w środku ma pozwalać na operowanie nieznaną 
>> iloscią plikó wirtualnych, dynamicznie je tworząc, kasując, 
>> powiększając, nadpisując. Mniej więcej to co robi normalny filesystem 
>> na normalnym dysku.
> Kluczowe pytanie do czego ci to potrzebne bo nadal przy tej "dawce 
> wiedzy" będę sie upierał że wystarczą ci strumienie by to napisać

Nie, nie wystarczą. Aplikacja jest komercyjna.

> Strumienie nie dadzą rady w momencie gdy potrzebujesz z tego wycisnąć 
> max wydajności

Dalej nie pojmuje co niby te strymienie mają mi dopomóc w problemie? 
std::fstream i co dalej? jest jakis std::filesystem?

> Zasugerowałem format VDI lub zbuduj własny format co nie jest takie 
> trudne jak zglebisz temat formatu plików pozwalający przechowywać obraz 
> dysku.

Ale to są tylko trywialne translatory blok wirtualny->pozycja w pliku + 
trim.

> Moim zdaniem błędnie się zasugerowałeś że to ma być FileSystem

To ma być filesystem, bo w API mowa o plikach a bie blokach na dysku.

> Moja rada poczytaj o tym jak się konstruję formaty plików

A jak się konstruuje formaty plików? Jest jakiś poradnik do tego?

> Pytanie czy da się strumieniami twoim zdaniem zapakować kilka plików do 
> jednego pliku?

Da się, ale nie da się potem na tym pracować. Zwiększ rozmiar środkowego.

> Zadaje to pytanie nie po by się z Ciebie nabijać tylko po to by 
> zrozumieć czemu sądzisz ze pliki typu qcow2/vdi są systemami plików.

Nie sądzę tak.

On 06/04/2021 00:31, J-23 wrote:
> Zapomniałem się odnieść do tego co wyżej. To zdziwisz się czym to jest 
> ogarnięte np w VirtualBox.

W VirutalBox filesystemy na wirtualny dyskach NIE są ogarnięte, bo to 
zadanie pracujących w środku OSów. Ogólnie VB nie ma implementacji 
filesystemów w tym pliku, tylko nieskopoziomową translację bloków w 
pliku + trim i tyle jest wystarczające aby resztą zająć się guest.

> Mieszasz pojęcia nie rozumiesz co to jest format pliku.

Najprawdopodobniej żyje w innej rzeczywistości.

> Mylisz go z 
> systemem pliku nawet mam wrażenie że nie ogarniasz tego co twierdzisz ze 
> ogarniasz

Bardzo możliwe, ale zwróc uwagę że wiele osób z tej grupy ogarnęło. To 
powoduje że zacząćbym się zastanawiać nie czy ja nie ogarniam, tylko czy 
Ty. Nie masz takiej wątpliwości?

> 1. Random access - masz na myśli losowy dostęp? No i nie ma on nic 
> wspolnego ze strumeniami tak?

Twoja rada "użyj strumieni" jest absurdalna. To jakby koś pytając "jak 
zrobić drzewo czerwono-czarne" dostał odpowiedź "użyj procedur". Bez 
wątpienia jest celna i bezużyteczna.

Mogę uzyć czekokolwiek, mogę użyć strumieni z random access, bazy danych 
czy kart perforowanych. Mało ważne, mam tylko zapisywać bloki w pliku na 
okreslonych pozycjach i to jest *trywialne* i kompletnie nieistotne. 
Istotne jest sterowanie tym mechanizmem, które nazywamy filesystemem.

> 2. Trim - to nawet pozostawie bez komentarza

To źle, bo ten trim jest krytycznie istotny aby całość miała sens.

> 3. Gerbage Collector że tak zapytam co ma wspólnego z system plikow - 
> nic.

Czyli nie masz śladu pojmowania na czym polegają problemy z którymi 
tutaj należy się mierzyć.

> Ma do czynienia z zarządzaniem pamięcią a zarządzanie pamięcią a 
> system plików to dwa odrębne tematy

...i nie rozumiesz nawet śladu abstrakcji czym jest pamięć.

Podpowiem, chociaż wydaje się to bezcelowe: zastanów się czym jest 
garbage collecting w kontekście *pliku* swap.

2021-04-06 o 10:58 +0200, heby napisał:
> Więc jeszcze raz: chciałbym kilka plików, któe generuje apliakcja, 
> zawszeć w jednym. W przewieństwie do pakowania a'la zip, to ma być 
> dostepne jak normalne pliki, czyli mogę do niczh coś dopisać,
> trimować, tworzyć i kasować.

Pewno umiesz korzystać z wyszukiwarki tak samo jak ja i już to
widziałeś, ale jeśli nie... Być może warte przejrzenia, bo z opisu
brzmi jak dokładnie to, czego szukasz.

https://code.google.com/archive/p/whefs/

"similar to conventional archives (e.g. zip files), except that this
library provides random-access read/write support to the filesystem via
an API similar to the conventional fopen(), fread(), fwrite() and
friends."

Mateusz

On 06/04/2021 11:22, Mateusz Viste wrote:
> brzmi jak dokładnie to, czego szukasz.
> https://code.google.com/archive/p/whefs/

Tak, oglądałem ten projekt z grubsza już, mam go w planie obejrzeć 
dokładnie za kilka tyg. Obawiam się że nie trimuje pliku fizycznego co w 
zasadzie powoduje dyskwalifikację, nie wspiera wąktów (i locków) i ma 
jakies ograniczenia na ilość inodes. Przypuszczalnie będzie raczej 
jakimś konceptem niż implementacją.

W dniu 2021.04.06 o 10:58, heby pisze:
> On 05/04/2021 23:55, J-23 wrote:
>>> Zostało to wyjaśnione.
>> Nie zostało
> 
> Więc jeszcze raz: chciałbym kilka plików, któe generuje apliakcja, 
> zawszeć w jednym. W przewieństwie do pakowania a'la zip, to ma być 
> dostepne jak normalne pliki, czyli mogę do niczh coś dopisać, trimować, 
> tworzyć i kasować.
> 

Rozumiem doskonale i próbuje dać Ci podstawowe kroki od czego zacząć

> Unikam wtedy bałaganu w postaci katalogu z plikami, w których user może 
> coś uszkodzić. Praktyka pokazała że to *krytyczne*.
> 
>>> Więc jak?
>> Możesz to zrobić na co najmniej dwa sposoby
>> 1. Korzystając ze strumieni i pliku binarnego
> 
> Omijasz podstawowy problem. Strukturę tego pliki "binarnego". Skupiasz 
> się na trzecirzędnych duprelach.
> 

Taka strukture musisz sobie napisać lub skorzystać z instiejącej (mowiac 
z istniejącej mam na myśli to że korzystasz z formatu który Ci to umożliwa)

>> 2. Wykorzystując formaty tj VDI
>> https://www.arysontechnologies.com/blog/how-to-open-vdi-file/#:~:text=VDI%20or%20Virtual%20Drive%20Format,Windows%20and%20other%20operating%20systems. 
> 
> 
> To bardzo milutkie, ale to tylko 1/10 sukcesu. Co z filesystemem? Mam 
> sobie skombinować skądś ext4 w wersji bez kernela?


tlumacze po raz enty ty nie musisz mieć filesystemu skupiasz się nie na 
tym co trzeba

> 
>> Dostęp do źrodeł masz opisy formatu znajdziesz też w sieci
> 
> Ale to nie jest format zapisu plików, tylko format zapisu *dysku*. 
> Brakuje tej warstwy o której mowa w temacie.
> 


dla przykładu VDI jest plikiem i on ma odpowiedni format który pozwala 
przechowywać obraz dysku tak? czy nie?

>>> *DOSKONALE* wiem co.
>> Bez szyderstwa. Napisz więcej co to ma robić bo mam wrażenie że 
>> strzelasz z armaty do wróbla
> 
> Napisałem wyżej.
> 
>>>> Chcesz budować Filesystem to pochwal się jak masz to ogarnięte do 
>>>> tej pory
>> Bo to co chcesz zbudować jest formatem pliku emulującym działanie 
>> systemu plików a to różnica
> 
> Nie, to nie jest róznica, dokładnie to chce uzyskać od samego początku.

Tylko po co?

> 
>> Napisałem już w pierwszym moim poście że musisz zbudować odpowiedni 
>> format pliku
> 
> Świetnie:
> 
> Pacjet: Panie doktorze co dalej?
> Doktur: Powinien pan wyzdrowieć, od tego proszę zacząć.
> 
>> Nawet przywołane przeze mnie VDI jest formatem pliku a nie systemem 
>> plików
> 
> No własnie, dlatego jest poza tematem. Ogólnie jeśli mam już bloki, to 
> abstrakcja zapisująca je do pliku jest mało istotną duperelą. Skupiasz 
> się na nieistotnym technicznie detalu.
>

Wlasnie ty się skupiasz na czymś co ci jest zbędne przynajmniej na 
obecnym etapie

>>> Poczytaj wątek. Mam możliwosć schowania tego za abstrackją i 
>>> aktualnie używam database. Ale database jest marną emulacją.
>> Po co ci Database?
> 
> Aby emulować filesystem w pliku na potrzeby unit testów.
> 
>>> Bardzo dobra rada. Problem w tym, że kod do większości filesystemów 
>>> jest przesadnie zagmatwany aby można było wyłuskać z niego sensowne 
>>> abstrakcje. A wiele oglądałem. Najzwyczajniej, produkcyjne 
>>> filesystemy są optymalizowane a nie pisane po to aby je podziwiać.
>> Teraz jak wiem o co ci chodzi to odpowiem tak. Przejrzyj formaty które 
>> to umożliwiają przechowywać obraz dysku np wspomniany przeze mnie VDI
> 
> Formaty maszyn wirtualnych służa tylko do tego aby gołe sektory trzymać 
> w jakiś mniej-wiecej optymalny sposób w jednym pliku.
> 

Zajrzyj w format VDI jak to jest zrobione. Nawet ten prosty parser w 
javie który podesłałem pokazuje że jest to plik o danym formacie.

> Niejak nie pomagają mi w wyższej warstwie abstrackji typu "jak trzymać 
> pliki w tym pliku".

Każdy plik ma określoną strukturę. Znajac ja pisząc odpowiednia obsługe 
tej struktury mozesz ja czyta w dowolny sposb
> 
>> bo System plików będzie faktycznie mocno zagmatwany bo ty potrzebujesz 
>> 20% tego co w systemie plików jest zawarte
> 
> Raczej 80%. Poza katalogami i atrybutami, ale oba to chyba jakieś mało 
> istotne rzeczy.
> 
>>> Ma pracować na 1 pliku, a w środku ma pozwalać na operowanie nieznaną 
>>> iloscią plikó wirtualnych, dynamicznie je tworząc, kasując, 
>>> powiększając, nadpisując. Mniej więcej to co robi normalny filesystem 
>>> na normalnym dysku.
>> Kluczowe pytanie do czego ci to potrzebne bo nadal przy tej "dawce 
>> wiedzy" będę sie upierał że wystarczą ci strumienie by to napisać
> 
> Nie, nie wystarczą. Aplikacja jest komercyjna.

Strumienie są tylko narzedziem za pomocą których napiszesz odpowiednią 
strukture tego co ma zostać przechowywane a nie celem samym w sobie

> 
>> Strumienie nie dadzą rady w momencie gdy potrzebujesz z tego wycisnąć 
>> max wydajności
> 
> Dalej nie pojmuje co niby te strymienie mają mi dopomóc w problemie? 
> std::fstream i co dalej? jest jakis std::filesystem?
> 

Jak napisałem wyżej one są tylko środkiem za pomocą którego napiszesz 
sobie odpowiednią strukture

>> Zasugerowałem format VDI lub zbuduj własny format co nie jest takie 
>> trudne jak zglebisz temat formatu plików pozwalający przechowywać 
>> obraz dysku.
> 
> Ale to są tylko trywialne translatory blok wirtualny->pozycja w pliku + 
> trim.
> 
>> Moim zdaniem błędnie się zasugerowałeś że to ma być FileSystem
> 
> To ma być filesystem, bo w API mowa o plikach a bie blokach na dysku.
> 


o jakim api mówisz? to po pierwsze
Po drugie co to zmienia?

Ty masz mieć plik w którym będziesz sobie dowolnie mógł wykonywać 
operacje tj, czytanie/zapis/przesuniecie/obcięcie danych

i to potrafi niemal każdy plik kwestia by zrobić to teraz w miarę wydajnie

>> Moja rada poczytaj o tym jak się konstruję formaty plików
> 
> A jak się konstruuje formaty plików? Jest jakiś poradnik do tego?
> 

poradnika nie ma. Ale są opisy formatu plików jak zobaczysz jak ne są 
napisane zlapiesz jak powinno się pisać dany format pliku


Mam gdzieś w swoich starych zasobach pisane chyba we FreePascalu opisany 
swój format pliku w którym przechowuje obiekty bazodanowe - tj 
DataSource/DataSet/Query

Moge je czytać jak chce ze środka pliku/ obcinać/dodawać itp

Jak chcesz mogę poszukać/wrzucić i sobie zobaczysz


>> Pytanie czy da się strumieniami twoim zdaniem zapakować kilka plików 
>> do jednego pliku?
> 
> Da się, ale nie da się potem na tym pracować. Zwiększ rozmiar środkowego.

Bzdura że się nie da da się. A ty myślisz że jak to robią formaty które 
przechowują obrazy dysków?

Fakt jest jeden jest z tym masa pracy by to osiągnąć stąd proponuje użyć 
jakiegoś gotowego formatu by oszczędzić sobie pracy

Pozdrawiam
J-23

W dniu 2021.04.06 o 11:06, heby pisze:
> 
> ...i nie rozumiesz nawet śladu abstrakcji czym jest pamięć.
> 
> Podpowiem, chociaż wydaje się to bezcelowe: zastanów się czym jest 
> garbage collecting w kontekście *pliku* swap.

Gerbage Collecting tylko sprząta pamięć nic wiecej.

Ważniejszą sprawą jest jak to robi, a robi to bezwzględu na system 
plików bo Gerbage Collecting i system plików nawet o sobie wzajemnie nie 
wiedzą

Nie rozumiem tylko jednego. Dlaczego uparłeś się że to ma być system 
plików. Podpowiem może być to system plików ale jest to strzelanie z 
armaty do wróbla.

Po za tym nazywanie tego co chcesz zrobić systemem plików w mojej ocenie 
to jest nieporozumienie.

Pozdrawiam
J-23

On 06/04/2021 16:54, J-23 wrote:
> Rozumiem doskonale i próbuje dać Ci podstawowe kroki od czego zacząć

Niezupełnie, podpowadasz na razie banały.

>> Omijasz podstawowy problem. Strukturę tego pliki "binarnego". Skupiasz 
>> się na trzecirzędnych duprelach.
> Taka strukture musisz sobie napisać

Tak, dokładnie.

> dla przykładu VDI jest plikiem i on ma odpowiedni format który pozwala 
> przechowywać obraz dysku tak? czy nie?

Dla przykładu to ja mam zapisywać obrazy dysku czy pliki? No wiec 
podpowiem: pliki. Dużo plików. Po co mi kontener na obrazy dysku tym 
bardziej że jest trywialny (poza trim, ale do ogarnięcia)?

>> Nie, to nie jest róznica, dokładnie to chce uzyskać od samego początku.
> Tylko po co?

Ponieważ rozwiazuje to jakies zagadnienia spójności danych.

>> No własnie, dlatego jest poza tematem. Ogólnie jeśli mam już bloki, to 
>> abstrakcja zapisująca je do pliku jest mało istotną duperelą. Skupiasz 
>> się na nieistotnym technicznie detalu.
> Wlasnie ty się skupiasz na czymś co ci jest zbędne przynajmniej na 
> obecnym etapie

Cała reszta to duperele ;)

> Zajrzyj w format VDI jak to jest zrobione. Nawet ten prosty parser w 
> javie który podesłałem pokazuje że jest to plik o danym formacie.

Używasz słowa "format" tak ja by rozwiązywało wszelakie problemy :) A 
potrafisz tym prostym parserem w javie odczytać *pliki* na *partycji* na 
tym pliku obrazu dysku?

>> Niejak nie pomagają mi w wyższej warstwie abstrackji typu "jak trzymać 
>> pliki w tym pliku".
> Każdy plik ma określoną strukturę. Znajac ja pisząc odpowiednia obsługe 
> tej struktury mozesz ja czyta w dowolny sposb

Znowu banał. Tak, to wszystko jest oczywiste. "Znając odpowiednie klucze 
można rozszyfrować transmisje.". Tak, to bardzo pomaga.

> Strumienie są tylko narzedziem za pomocą których napiszesz odpowiednią 
> strukture tego co ma zostać przechowywane a nie celem samym w sobie

No tak, ale tłumaczysz komuś że procedury są tylko narzedziem do 
zrobienia AI i dalej sobie powinien poradzić.

>> Dalej nie pojmuje co niby te strymienie mają mi dopomóc w problemie? 
>> std::fstream i co dalej? jest jakis std::filesystem?
> Jak napisałem wyżej one są tylko środkiem za pomocą którego napiszesz 
> sobie odpowiednią strukture

No tak, ale to oczywisty banał. Dalej nie rozumiesz że *znacząco* 
większym prolemem jest ta struktura i to jest problem algorytmiczny a 
nie pierdołowatych strumieni.

>> To ma być filesystem, bo w API mowa o plikach a bie blokach na dysku.
> o jakim api mówisz?

Moim.

> Po drugie co to zmienia?

Aby przejść z raw image dysku na pojęcie wirtualnych plików, trzeba cioś 
więcej niż fstream. To "coś" to filesystem.

> Ty masz mieć plik w którym będziesz sobie dowolnie mógł wykonywać 
> operacje tj, czytanie/zapis/przesuniecie/obcięcie danych

Super, znowu banały. Tak, to wszystko mogę zrobić. Ale nijak z teo nie 
wynika jaka algortmika stoi za stworzeniem, dzięki tym prostym 
operacjom, wyższej warstwy abstrakcji jak "pliki".

>>> Moja rada poczytaj o tym jak się konstruję formaty plików
>> A jak się konstruuje formaty plików? Jest jakiś poradnik do tego?
> poradnika nie ma. Ale są opisy formatu plików jak zobaczysz jak ne są 
> napisane zlapiesz jak powinno się pisać dany format pliku

:D Przepraszam ale ja się pogubiłem. Istnieje jakiś *standard* robienia 
formatów plików który mnie poratuje? Jakaś dobra szkoła która magicznie 
rozwiąże moje problemy? Wow. Niestety to tak nie działa. Twój "format 
pliku" to właśnie ten filesystem.

> Mam gdzieś w swoich starych zasobach pisane chyba we FreePascalu opisany 
> swój format pliku w którym przechowuje obiekty bazodanowe - tj 
> DataSource/DataSet/Query
> Moge je czytać jak chce ze środka pliku/ obcinać/dodawać itp
> Jak chcesz mogę poszukać/wrzucić i sobie zobaczysz

Wrzuć.

>>> Pytanie czy da się strumieniami twoim zdaniem zapakować kilka plików 
>>> do jednego pliku?
>> Da się, ale nie da się potem na tym pracować. Zwiększ rozmiar środkowego.
> Bzdura że się nie da da się. A ty myślisz że jak to robią formaty które 
> przechowują obrazy dysków?

Robią to używając innej wastwy abstrakcji niż fsream. Bingo, 
Zrozumiałeś, że fstream to tylko jakaś duperela, kompletnie tutaj 
nieistotna. Równie dobrze to może być kawałek RAMu albo nbd.

> Fakt jest jeden jest z tym masa pracy by to osiągnąć stąd proponuje użyć 
> jakiegoś gotowego formatu by oszczędzić sobie pracy

O to to! Najlepiej "formatu pliku filesystemu".

Może problem polega na tym że traktujesz mnie jak idiotę i tłumaczysz że 
programowanie polega na pisaniu procedur i używaniu fstream a resztę 
magicznie dopisują wróżki? Jak byłbym wyjątkowo głupi, to bym filesystem 
napisał samodzielnie. Obecnie mam już na karku kilka lat i zdaje sobie 
sprawę z moich słabych kompetencji w tym temacie, więc pytam o radę. Nie 
wykluczone że napiszę to samodzielnie, ale... doświaczenie podpowiada że 
są lepsi ode mnie i dawno to zrobili.

On 06/04/2021 17:08, J-23 wrote:
>> ...i nie rozumiesz nawet śladu abstrakcji czym jest pamięć.
>> Podpowiem, chociaż wydaje się to bezcelowe: zastanów się czym jest 
>> garbage collecting w kontekście *pliku* swap.
> Gerbage Collecting tylko sprząta pamięć nic wiecej.

Wiec co sprząta swap redukując jego rozmiar?

Swoją drogą patrz, tutaj jakieś tępe ćwoki nie wiedzieli, że to tylko 
dotyczy pamieci i ośmielili się zrobic to w db:

https://public.support.unisys.com/aseries/docs/clearpath-mcp-18.0/86000759-621/section-000017440.html

https://www.firebirdsql.org/pdfmanual/html/gfix-housekeeping.html

https://docs.oracle.com/cd/E23943_01/admin.1111/e10029/gar_coll.htm#OIDAG089

Świat jest pełen świrów, nie?

> Ważniejszą sprawą jest jak to robi, a robi to bezwzględu na system 
> plików bo Gerbage Collecting i system plików nawet o sobie wzajemnie nie 
> wiedzą

Widomo, że o sobie nie wiedzą, w końcu Ty nie pojmujesz po co mi GC w 
*pliku* a ja nie rozumiem o co pytam.

> Nie rozumiem tylko jednego. Dlaczego uparłeś się że to ma być system 
> plików. Podpowiem może być to system plików ale jest to strzelanie z 
> armaty do wróbla.

Zaproponuj coś innego co w *jednym* pliku trzyma:
1) strumienie o dowolnych nazwach
2) pozwala je kasować i tworzyć
3) zezwala na dostęp z kilku wątków na raz
4) pozwala je dopisywać i skracać niezależnie
5) główny plik ma rozmiar adekwatny do ilości danych w środku

Musisz bardzo uważać, bo cokolwiek zrobisz, będzie to miało pełne prawo 
nazywać się filesystemem.

> Po za tym nazywanie tego co chcesz zrobić systemem plików w mojej ocenie 
> to jest nieporozumienie.

Też uważam że to nieporozumienie, bo Windows z tego nie wystartuje, więc 
to żaden filesystem.

W dniu 2021.04.06 o 18:01, heby pisze:
> On 06/04/2021 16:54, J-23 wrote:
>> Rozumiem doskonale i próbuje dać Ci podstawowe kroki od czego zacząć
> 
> Niezupełnie, podpowadasz na razie banały.
> 
>>> Omijasz podstawowy problem. Strukturę tego pliki "binarnego". 
>>> Skupiasz się na trzecirzędnych duprelach.
>> Taka strukture musisz sobie napisać
> 
> Tak, dokładnie.

Dobrze ze zacząłeś kumać przynajmniej to.

> 
>> dla przykładu VDI jest plikiem i on ma odpowiedni format który pozwala 
>> przechowywać obraz dysku tak? czy nie?
> 
> Dla przykładu to ja mam zapisywać obrazy dysku czy pliki? No wiec 
> podpowiem: pliki. Dużo plików. Po co mi kontener na obrazy dysku tym 
> bardziej że jest trywialny (poza trim, ale do ogarnięcia)?
> 

Podałem przykład VDI bo on w duzej części rozwiązuje twoje problemy. Nie 
jest to 100% rozwiązanie Twoich problemów ale myśle że w dużym stopniu 
by Ci pokazało jak można iść dalej

>>> Nie, to nie jest róznica, dokładnie to chce uzyskać od samego początku.
>> Tylko po co?
> 
> Ponieważ rozwiazuje to jakies zagadnienia spójności danych.
> 
>>> No własnie, dlatego jest poza tematem. Ogólnie jeśli mam już bloki, 
>>> to abstrakcja zapisująca je do pliku jest mało istotną duperelą. 
>>> Skupiasz się na nieistotnym technicznie detalu.
>> Wlasnie ty się skupiasz na czymś co ci jest zbędne przynajmniej na 
>> obecnym etapie
> 
> Cała reszta to duperele ;)


Tylko Ci sie wydaje że to są duperele

> 
>> Zajrzyj w format VDI jak to jest zrobione. Nawet ten prosty parser w 
>> javie który podesłałem pokazuje że jest to plik o danym formacie.
> 
> Używasz słowa "format" tak ja by rozwiązywało wszelakie problemy :) A 
> potrafisz tym prostym parserem w javie odczytać *pliki* na *partycji* na 
> tym pliku obrazu dysku?
> 


bo koniec końców rozwiązuje Twoje problemy właśnie slowo "format" ale ty 
nie rozumiesz tego bo skupileś się na Filesystem

>>> Niejak nie pomagają mi w wyższej warstwie abstrackji typu "jak 
>>> trzymać pliki w tym pliku".
>> Każdy plik ma określoną strukturę. Znajac ja pisząc odpowiednia 
>> obsługe tej struktury mozesz ja czyta w dowolny sposb
> 
> Znowu banał. Tak, to wszystko jest oczywiste. "Znając odpowiednie klucze 
> można rozszyfrować transmisje.". Tak, to bardzo pomaga.
> 

Nawet nie starasz się zroumieć tego co czytasz. Szkoda bo to pogłębia 
problem zamiast go zmniejszać


>> Strumienie są tylko narzedziem za pomocą których napiszesz odpowiednią 
>> strukture tego co ma zostać przechowywane a nie celem samym w sobie
> 
> No tak, ale tłumaczysz komuś że procedury są tylko narzedziem do 
> zrobienia AI i dalej sobie powinien poradzić.
> 

Tlumacze że za pomocą strumieni musisz zbudować odpowiednia strukturę o 
czym pisałem już w pierwszym poście

>>> Dalej nie pojmuje co niby te strymienie mają mi dopomóc w problemie? 
>>> std::fstream i co dalej? jest jakis std::filesystem?
>> Jak napisałem wyżej one są tylko środkiem za pomocą którego napiszesz 
>> sobie odpowiednią strukture
>
> No tak, ale to oczywisty banał. Dalej nie rozumiesz że *znacząco* 
> większym prolemem jest ta struktura i to jest problem algorytmiczny a 
> nie pierdołowatych strumieni.


A ty nie rozumiesz że Twój problem został dawno rozwiązany i klucza do 
niego nikt ci nie poda na Grupie Dyskusyjnej bo jest to złożony problem 
i chcąc się dowiedzieć jak to można rozwiązać musisz niestety babrać się 
w źródłach jakiegoś projektu

> 
>>> To ma być filesystem, bo w API mowa o plikach a bie blokach na dysku.
>> o jakim api mówisz?
> 
> Moim.

O to dowiadujemy się o czymś zupelnie nowym :)

> 
>> Po drugie co to zmienia?
> 
> Aby przejść z raw image dysku na pojęcie wirtualnych plików, trzeba cioś 
> więcej niż fstream. To "coś" to filesystem.
> 

Odkrywczy jesteś tylko nie wiesz ze mieszasz pojęcia.

Poczytaj co to jest System plików bo mam wrażenie że gdzieś po drodze 
szukania rozwiązania problemu sie pogubiłeś
>> Ty masz mieć plik w którym będziesz sobie dowolnie mógł wykonywać 
>> operacje tj, czytanie/zapis/przesuniecie/obcięcie danych
> 
> Super, znowu banały. Tak, to wszystko mogę zrobić. Ale nijak z teo nie 
> wynika jaka algortmika stoi za stworzeniem, dzięki tym prostym 
> operacjom, wyższej warstwy abstrakcji jak "pliki".
> 


Wytłumacz może nam wszystkim po co ci tworzyć coś takiego jak "wirtualny 
plik" w swoim "wirtualnym systemie plikow"? Co ty budujesz symulator dysku?

>>>> Moja rada poczytaj o tym jak się konstruję formaty plików
>>> A jak się konstruuje formaty plików? Jest jakiś poradnik do tego?
>> poradnika nie ma. Ale są opisy formatu plików jak zobaczysz jak ne są 
>> napisane zlapiesz jak powinno się pisać dany format pliku
> 
> :D Przepraszam ale ja się pogubiłem. Istnieje jakiś *standard* robienia 
> formatów plików który mnie poratuje? Jakaś dobra szkoła która magicznie 
> rozwiąże moje problemy? Wow. Niestety to tak nie działa. Twój "format 
> pliku" to właśnie ten filesystem.


Pojecia "Format pliku" a "Filesystem" to są 2 różne pojęcia zrozum to.
> 
>> Mam gdzieś w swoich starych zasobach pisane chyba we FreePascalu 
>> opisany swój format pliku w którym przechowuje obiekty bazodanowe - tj 
>> DataSource/DataSet/Query
>> Moge je czytać jak chce ze środka pliku/ obcinać/dodawać itp
>> Jak chcesz mogę poszukać/wrzucić i sobie zobaczysz
> 
> Wrzuć.


Jutro postaram się wrzucić

> 
>>>> Pytanie czy da się strumieniami twoim zdaniem zapakować kilka plików 
>>>> do jednego pliku?
>>> Da się, ale nie da się potem na tym pracować. Zwiększ rozmiar 
>>> środkowego.
>> Bzdura że się nie da da się. A ty myślisz że jak to robią formaty 
>> które przechowują obrazy dysków?
> 
> Robią to używając innej wastwy abstrakcji niż fsream. Bingo, 
> Zrozumiałeś, że fstream to tylko jakaś duperela, kompletnie tutaj 
> nieistotna. Równie dobrze to może być kawałek RAMu albo nbd.
> 
>> Fakt jest jeden jest z tym masa pracy by to osiągnąć stąd proponuje 
>> użyć jakiegoś gotowego formatu by oszczędzić sobie pracy
> 
> O to to! Najlepiej "formatu pliku filesystemu".
> 
> Może problem polega na tym że traktujesz mnie jak idiotę i tłumaczysz że 
> programowanie polega na pisaniu procedur i używaniu fstream a resztę 
> magicznie dopisują wróżki? Jak byłbym wyjątkowo głupi, to bym filesystem 
> napisał samodzielnie. Obecnie mam już na karku kilka lat i zdaje sobie 
> sprawę z moich słabych kompetencji w tym temacie, więc pytam o radę. Nie 
> wykluczone że napiszę to samodzielnie, ale... doświaczenie podpowiada że 
> są lepsi ode mnie i dawno to zrobili.


Jakbyś chwile pomyślał to byś się zastanowił i napisał nam wszystkim 
czego ty tak naprawdę potrzebujesz. Bo Filesystem to

- Katalogi
- pliki
- uprawnienia
- dodawanie/usuwanie pliku/katalogu

itd

a mam wrażenie że tobie jest to zbędne po tym co opisujesz

PS. Poszukaj w necie swego czasu byl dostępny opis FiieSystem Fat16 i 
może wtedy zrozumiesz różnice między formatem pliku a filesystem


Pozdrawiam
J-23

W dniu 2021.04.06 o 18:12, heby pisze:
> On 06/04/2021 17:08, J-23 wrote:
> Świat jest pełen świrów, nie?

Zrobili na bazie danych i dobrze ale ty nie widzisz już tego że baza 
danych i "GC" o ktorym mówisz leżą zupełnie w innej warstwie programowej

Gdyby tak było jak mowisz plik z bazą od Fireberda zmniejszałby się po 
usunięciu rekordu a tak nie jest.
> 
>> Ważniejszą sprawą jest jak to robi, a robi to bezwzględu na system 
>> plików bo Gerbage Collecting i system plików nawet o sobie wzajemnie 
>> nie wiedzą
> 
> Widomo, że o sobie nie wiedzą, w końcu Ty nie pojmujesz po co mi GC w 
> *pliku* a ja nie rozumiem o co pytam.
> 

Ja doskonale rozumiem po co Ci GC problem w tym że ty nie rozumiesz że 
projektując czy to Filesystem czy strukture pliku nie ma on kompletnie 
znaczenia.

Ma znaczenie tylko przy usuwaniu zawartości a to jest juz operacja która 
do struktury ma się jak piesc do oka na etapie projektowania struktury

>> Nie rozumiem tylko jednego. Dlaczego uparłeś się że to ma być system 
>> plików. Podpowiem może być to system plików ale jest to strzelanie z 
>> armaty do wróbla.
> 
> Zaproponuj coś innego co w *jednym* pliku trzyma:
> 1) strumienie o dowolnych nazwach
> 2) pozwala je kasować i tworzyć
> 3) zezwala na dostęp z kilku wątków na raz
> 4) pozwala je dopisywać i skracać niezależnie
> 5) główny plik ma rozmiar adekwatny do ilości danych w środku
>

A robileś chociaż jakieś testy by spróbować jak to wychodzi? Bo zapisać 
te punkty tworząc odpowiedni format nie ma z tym większego problemu.

Problem jest w tym że nie wiem co zapisujesz więc mogą być problemy 
wydajnościowe


> Musisz bardzo uważać, bo cokolwiek zrobisz, będzie to miało pełne prawo 
> nazywać się filesystemem.
> 

Nie i tutaj się nie zgodzę ale to już czysty spór o nazewnictwo co tutaj 
na Grupie jest bezcelowe

Pozdrawiam
J-23

On 06/04/2021 19:41, J-23 wrote:
>> Dla przykładu to ja mam zapisywać obrazy dysku czy pliki? No wiec 
>> podpowiem: pliki. Dużo plików. Po co mi kontener na obrazy dysku tym 
>> bardziej że jest trywialny (poza trim, ale do ogarnięcia)?
> Podałem przykład VDI bo on w duzej części rozwiązuje twoje problemy.

Nic nie rozwiązuje. Ja w ogóle nie mam problemu z zapiem blokowej 
struktury na dysku. To zupełnie nieistotne.

> bo koniec końców rozwiązuje Twoje problemy właśnie slowo "format" ale ty 
> nie rozumiesz tego bo skupileś się na Filesystem

To jedno i to samo. Filesystem okresla strukturę pliku. Masz tutaj swój 
"format".

> Nawet nie starasz się zroumieć tego co czytasz.

Nic tam nie ma do rozumienia. Proponujesz użycie trywialnego kontenera 
random access zorientowanego na bloki.

Ja po drugiej stronie mam API plikowe.

W środku jest czarna dziura. W dodatku skomplikowana, którą nazywasz 
"formatem" - weź se napisz. No więc to nie jest trywialne.

>> No tak, ale tłumaczysz komuś że procedury są tylko narzedziem do 
>> zrobienia AI i dalej sobie powinien poradzić.
> Tlumacze że za pomocą strumieni musisz zbudować odpowiednia strukturę o 
> czym pisałem już w pierwszym poście

"Procedurami napisze Pan dowolne AI. Proszę".

> A ty nie rozumiesz że Twój problem został dawno rozwiązany i klucza do 
> niego nikt ci nie poda na Grupie Dyskusyjnej bo jest to złożony problem 
> i chcąc się dowiedzieć jak to można rozwiązać musisz niestety babrać się 
> w źródłach jakiegoś projektu

To już rozwiązaniem nie jest plik z maszyny wirtualnej?

Po pierwsze, niekoniecze szukam gotowca. Literatura też się nada.

Po drugie, nie doceniasz ludzi, którzy tutaj pisują.

>> Moim.
> O to dowiadujemy się o czymś zupelnie nowym :)

Nic dziwnego. Było to opisane w pierwszych paru linijkach pierwotnego postu.

>> Aby przejść z raw image dysku na pojęcie wirtualnych plików, trzeba 
>> cioś więcej niż fstream. To "coś" to filesystem.
> Odkrywczy jesteś tylko nie wiesz ze mieszasz pojęcia.

Obawiam się że nie mieszam. Mogę był głupi, ale akurat na tym się trochę 
znam. Wbrew pozorom napisałem kilka rzeczy w życiu, były tem też proste 
filesystemy.

> Poczytaj co to jest System plików bo mam wrażenie że gdzieś po drodze 
> szukania rozwiązania problemu sie pogubiłeś

To coś, co transluje API plikowe na API blokowe/clusterowe, w sensie 
jakim chce go użyć tutaj. Pomijam FS sieciowe, nie mają tutaj zastosowania.

> Wytłumacz może nam wszystkim po co ci tworzyć coś takiego jak "wirtualny 
> plik" w swoim "wirtualnym systemie plikow"? Co ty budujesz symulator dysku?

Napisałem to kilka razy. Napiszę ponownie: aby utrzymać spójnośc danych. 
Na ten przykład wiele programów pakuje swoje małe pliczki do jednego 
ZIPa czy tar.gz, zmienia mu nazwę i masz .foo.

To ja chce wiecej. Chce móc na tym pracować, a nie tylko używać jako 
storage.

> Pojecia "Format pliku" a "Filesystem" to są 2 różne pojęcia zrozum to.

W tym przypadku niestety nie.

Polecam konsultację z mount -o loop pod Linuxem, może zauważysz, że 
*plik* mozna traktować jako nośnik filesystemu. Jego "format" staje się 
wtedy filesystemem wprost.

> Jakbyś chwile pomyślał to byś się zastanowił i napisał nam wszystkim 
> czego ty tak naprawdę potrzebujesz. Bo Filesystem to
> - Katalogi

Zbędne.

> - pliki

Tak.

> - uprawnienia

Zbędne.

> - dodawanie/usuwanie pliku/katalogu

Tak, bez katalogu.

> itd

Niestety w itd znajduje się mięsko. O ile powyższe punkty mogę sobie 
napisać, to zapominasz o:
1) wielodostępie (a tym samym blokowaniu). Z watków (łatwe) i procesów 
(łomatko!)
2) trim, aby nie puchło bez powodu
3) garbage collecting aby nie puchło bez powodu
4) kronikowaniu

Innymi słowy internesuje mnie to "itd". Przykładowo, synchronizacja 
międzyprocesowa jest do ogarnięcia, ale idę o zaklad że zrobię to 
niewydajnie.

> PS. Poszukaj w necie swego czasu byl dostępny opis FiieSystem Fat16 i 
> może wtedy zrozumiesz różnice między formatem pliku a filesystem

Nie przypuszczam aby FAT obsługiwał poprawnie trim i GC. I nie wiem czy 
można go używać bez licencji (ktoś wie czy MS jeszcze grozi paluszkiem?).

On 06/04/2021 19:57, J-23 wrote:
>> Świat jest pełen świrów, nie?
> Zrobili na bazie danych i dobrze ale ty nie widzisz już tego że baza 
> danych i "GC" o ktorym mówisz leżą zupełnie w innej warstwie programowej

No ale zrobili to GC na bazie czy nie zrobili? Twierdzisz że GC to tylko 
na pamięci, a tutaj banda nieświadomych świrów zrobiła na plikach. 
Bezczelni.

> Gdyby tak było jak mowisz plik z bazą od Fireberda zmniejszałby się po 
> usunięciu rekordu a tak nie jest.

Przecież nie musi. GC może zwolnić miejsce na nowe dane, np w ciągłym bloku.

Ja chce zamiast tego relokować sektory i trimować końcówkę pliku.

Niewielka różnica.

>> Widomo, że o sobie nie wiedzą, w końcu Ty nie pojmujesz po co mi GC w 
>> *pliku* a ja nie rozumiem o co pytam.
> Ja doskonale rozumiem po co Ci GC

Przed chwilą on nie istniał w kontekście pliku. Ewoluujesz. To dobrze.

> problem w tym że ty nie rozumiesz że 
> projektując czy to Filesystem czy strukture pliku nie ma on kompletnie 
> znaczenia.

Ja ogólnie nie rozumiem moich pomysłów, dlatego oczekuje aby ktoś mi 
wyjaśnił że czegoś nie rozumiem ponieważ on czegoś nie rozumie. Typowy 
usenet.

> Ma znaczenie tylko przy usuwaniu zawartości a to jest juz operacja która 
> do struktury ma się jak piesc do oka na etapie projektowania struktury

Tak, oczywiście. Albo nie. W sumie nie wiem. Chyba zlaeży od tej 
mitycznej "struktury" którą można załatwić strumieniami.

>> Zaproponuj coś innego co w *jednym* pliku trzyma:
>> 1) strumienie o dowolnych nazwach
>> 2) pozwala je kasować i tworzyć
>> 3) zezwala na dostęp z kilku wątków na raz
>> 4) pozwala je dopisywać i skracać niezależnie
>> 5) główny plik ma rozmiar adekwatny do ilości danych w środku
> A robileś chociaż jakieś testy by spróbować jak to wychodzi? Bo zapisać 
> te punkty tworząc odpowiedni format nie ma z tym większego problemu.

"Jak Pan użyje procedur to można napisać dowolne AI do sterowania 
promami kosmicznymi. Proszę".

> Problem jest w tym że nie wiem co zapisujesz więc mogą być problemy 
> wydajnościowe

Znikome. Przy sprytnej obsłudze wirtualnego FS można założyć, że duże 
bloki danych mogą być ułozone jeden po drugim. Jak się ma GC to czemu 
nie defragmentację w tle.

>> Musisz bardzo uważać, bo cokolwiek zrobisz, będzie to miało pełne 
>> prawo nazywać się filesystemem.
> Nie i tutaj się nie zgodzę ale to już czysty spór o nazewnictwo co tutaj 
> na Grupie jest bezcelowe

Od dłuższe chwili spieramy się o to czy "format" i "filesystem" to to 
samo. Myślę że ludzkośc czeka na to rozstrzygnięcie, nieciepliwie. To 
esencja usenetu. Spierać się o to kto bardziej nie rozumie przedmiotu sporu.

W dniu 2021.04.06 o 20:17, heby pisze:
> On 06/04/2021 19:57, J-23 wrote:
>>> Świat jest pełen świrów, nie?
>> Zrobili na bazie danych i dobrze ale ty nie widzisz już tego że baza 
>> danych i "GC" o ktorym mówisz leżą zupełnie w innej warstwie programowej
> 
> No ale zrobili to GC na bazie czy nie zrobili? Twierdzisz że GC to tylko 
> na pamięci, a tutaj banda nieświadomych świrów zrobiła na plikach. 
> Bezczelni.
> 

Zwróć uwagę że GC odbywa sie podczas zupelnie oddzielnej operacji.

Tutaj projektaci w IB/FB nie przejmowali się tym na etapie tworzenia 
struktury i ty też nie powinieneś

>> Gdyby tak było jak mowisz plik z bazą od Fireberda zmniejszałby się po 
>> usunięciu rekordu a tak nie jest.
> 
> Przecież nie musi. GC może zwolnić miejsce na nowe dane, np w ciągłym 
> bloku.
> 
> Ja chce zamiast tego relokować sektory i trimować końcówkę pliku.
> 
> Niewielka różnica.

I w czym widzisz problem? bo ja żadnego mozesz taki plik obciac o 
określoną ilość bajtów i tyle

> 
>>> Widomo, że o sobie nie wiedzą, w końcu Ty nie pojmujesz po co mi GC w 
>>> *pliku* a ja nie rozumiem o co pytam.
>> Ja doskonale rozumiem po co Ci GC
> 
> Przed chwilą on nie istniał w kontekście pliku. Ewoluujesz. To dobrze.
> 

Mieszasz pojęcia i to strasznie

>> problem w tym że ty nie rozumiesz że projektując czy to Filesystem czy 
>> strukture pliku nie ma on kompletnie znaczenia.
> 
> Ja ogólnie nie rozumiem moich pomysłów, dlatego oczekuje aby ktoś mi 
> wyjaśnił że czegoś nie rozumiem ponieważ on czegoś nie rozumie. Typowy 
> usenet.

Jak już wspomnialem mieszasz pojęcia i to powoduje "szum" w tym co 
chcesz przekazać
> 
>> Ma znaczenie tylko przy usuwaniu zawartości a to jest juz operacja 
>> która do struktury ma się jak piesc do oka na etapie projektowania 
>> struktury
> 
> Tak, oczywiście. Albo nie. W sumie nie wiem. Chyba zlaeży od tej 
> mitycznej "struktury" którą można załatwić strumieniami.
> 

Zostawmy strumienie w spokoju bo widzę że nie rozumiesz dalej.

Strumienie są tylko narzędziem do osiągniecia celu ale Tobie.
>>> Zaproponuj coś innego co w *jednym* pliku trzyma:
>>> 1) strumienie o dowolnych nazwach
>>> 2) pozwala je kasować i tworzyć
>>> 3) zezwala na dostęp z kilku wątków na raz
>>> 4) pozwala je dopisywać i skracać niezależnie
>>> 5) główny plik ma rozmiar adekwatny do ilości danych w środku
>> A robileś chociaż jakieś testy by spróbować jak to wychodzi? Bo 
>> zapisać te punkty tworząc odpowiedni format nie ma z tym większego 
>> problemu.
> 
> "Jak Pan użyje procedur to można napisać dowolne AI do sterowania 
> promami kosmicznymi. Proszę".
> 


Trzymaj się tematu bo odpływasz. Naprawde masz problem z zakodowaniem 
tego co wypisałeś w punktach w formie klasy z metodą SaveToFile i potem 
odczytać w całości lub po fragmencie? Bo zacząłbym od tego i zobaczyłbym 
gdzie leży problem? Tzn czy mam problemy wydajnościowe, z dostępem itp

Pozdrawiam
J-23

W dniu 2021.04.06 o 20:08, heby pisze:
> On 06/04/2021 19:41, J-23 wrote:
>>> Dla przykładu to ja mam zapisywać obrazy dysku czy pliki? No wiec 
>>> podpowiem: pliki. Dużo plików. Po co mi kontener na obrazy dysku tym 
>>> bardziej że jest trywialny (poza trim, ale do ogarnięcia)?
>> Podałem przykład VDI bo on w duzej części rozwiązuje twoje problemy.
> 
> Nic nie rozwiązuje. Ja w ogóle nie mam problemu z zapiem blokowej 
> struktury na dysku. To zupełnie nieistotne.

Rozwiązuje i to dużo problem w tym że tobie nawet się nie chce poszukać 
źrodeł by zobaczyć jak to jest tam zrobione

> 
>> bo koniec końców rozwiązuje Twoje problemy właśnie slowo "format" ale 
>> ty nie rozumiesz tego bo skupileś się na Filesystem
> 
> To jedno i to samo. Filesystem okresla strukturę pliku. Masz tutaj swój 
> "format".
> 
>> Nawet nie starasz się zroumieć tego co czytasz.
> 
> Nic tam nie ma do rozumienia. Proponujesz użycie trywialnego kontenera 
> random access zorientowanego na bloki.
> 

Bląd bo ja używam tego trywialnego kontenera do zbudowania "warstwy", 
"formatu", "filesystem" do ktora pozwoli Ci zapisać co chcesz i operować 
tym jak chcesz.

A biorąc Twoje wymagania pod uwage opisane w odrębnym poscie tego wątku 
nie są one skomplikowane

> Ja po drugiej stronie mam API plikowe.
> 
> W środku jest czarna dziura. W dodatku skomplikowana, którą nazywasz 
> "formatem" - weź se napisz. No więc to nie jest trywialne.

No i co tych plików nie możesz wpakować do tej struktury którą utworzysz?

> 
>>> No tak, ale tłumaczysz komuś że procedury są tylko narzedziem do 
>>> zrobienia AI i dalej sobie powinien poradzić.
>> Tlumacze że za pomocą strumieni musisz zbudować odpowiednia strukturę 
>> o czym pisałem już w pierwszym poście
> 
> "Procedurami napisze Pan dowolne AI. Proszę".
> 
>> A ty nie rozumiesz że Twój problem został dawno rozwiązany i klucza do 
>> niego nikt ci nie poda na Grupie Dyskusyjnej bo jest to złożony 
>> problem i chcąc się dowiedzieć jak to można rozwiązać musisz niestety 
>> babrać się w źródłach jakiegoś projektu
> 
> To już rozwiązaniem nie jest plik z maszyny wirtualnej?

Nie w 100% ale w 80% procentach masz w tym pliku gotowe roziwązanie 
wystarczy je zgłębić
> 
> Po pierwsze, niekoniecze szukam gotowca. Literatura też się nada.
> 
> Po drugie, nie doceniasz ludzi, którzy tutaj pisują.
> 
>>> Moim.
>> O to dowiadujemy się o czymś zupelnie nowym :)
> 
> Nic dziwnego. Było to opisane w pierwszych paru linijkach pierwotnego 
> postu.
> 
>>> Aby przejść z raw image dysku na pojęcie wirtualnych plików, trzeba 
>>> cioś więcej niż fstream. To "coś" to filesystem.
>> Odkrywczy jesteś tylko nie wiesz ze mieszasz pojęcia.
> 
> Obawiam się że nie mieszam. Mogę był głupi, ale akurat na tym się trochę 
> znam. Wbrew pozorom napisałem kilka rzeczy w życiu, były tem też proste 
> filesystemy.
> 

Wiec co ci przeszkadza wykorzystać to doświadczenie lub nawet pokazać to 
co zrobiles do tej pory (mam na mysli te male filesystem)

>> Poczytaj co to jest System plików bo mam wrażenie że gdzieś po drodze 
>> szukania rozwiązania problemu sie pogubiłeś
> 
> To coś, co transluje API plikowe na API blokowe/clusterowe, w sensie 
> jakim chce go użyć tutaj. Pomijam FS sieciowe, nie mają tutaj zastosowania.
> 
>> Wytłumacz może nam wszystkim po co ci tworzyć coś takiego jak 
>> "wirtualny plik" w swoim "wirtualnym systemie plikow"? Co ty budujesz 
>> symulator dysku?
> 
> Napisałem to kilka razy. Napiszę ponownie: aby utrzymać spójnośc danych. 
> Na ten przykład wiele programów pakuje swoje małe pliczki do jednego 
> ZIPa czy tar.gz, zmienia mu nazwę i masz .foo.

Wiec z czym masz problem z upakowanienem tego, z wielodostępem?

Bo ja tak naprawdę widze jeden problem z wielodostępem bo wielodostęp 
jest zależny od systemu plikow na jakim sie plik znajduje i to jedyny 
problem jaki widze na teraz

> 
> To ja chce wiecej. Chce móc na tym pracować, a nie tylko używać jako 
> storage.
> 

Od kiedy nie można pracować na "pliku"? Możesz go wczytywać fragmentami 
możesz go wczytać w calosci (o ile ci starczy pamięci) i na nim pracować

>> Pojecia "Format pliku" a "Filesystem" to są 2 różne pojęcia zrozum to.
> 
> W tym przypadku niestety nie.
> 
> Polecam konsultację z mount -o loop pod Linuxem, może zauważysz, że 
> *plik* mozna traktować jako nośnik filesystemu. Jego "format" staje się 
> wtedy filesystemem wprost.
> 

A to kolego zależy już faktycznie od Filesystem a nie od mount. Twoj 
Filesystem już i tak będzie leżał na jakimś systemie plików - chyba że 
będziesz go zapisywał bezpośrednio na dysku (z pominięciem systemu 
plików) w co wątpie

>> Jakbyś chwile pomyślał to byś się zastanowił i napisał nam wszystkim 
>> czego ty tak naprawdę potrzebujesz. Bo Filesystem to
>> - Katalogi
> 
> Zbędne.
> 
>> - pliki
> 
> Tak.
> 
>> - uprawnienia
> 
> Zbędne.
> 
>> - dodawanie/usuwanie pliku/katalogu
> 
> Tak, bez katalogu.
> 
>> itd
> 

To co jest plikiem a katalogiem to decyduje o tym znacznik w systemie plików

Skoro tworzysz strukture od zera to co za problem taki znacznik zrobić

> Niestety w itd znajduje się mięsko. O ile powyższe punkty mogę sobie 
> napisać, to zapominasz o:
> 1) wielodostępie (a tym samym blokowaniu). Z watków (łatwe) i procesów 
> (łomatko!)
Za to odpowiadać będzie system plików na którym będziesz trzymał swój 
FileSystem
> 2) trim, aby nie puchło bez powodu

Tutaj zależy jak zorganizujesz usuwanie elementów bo można to zrobić tak 
jak to robi np FB i będzie puchło a można usuwać konkretne bajty i nie 
będzie puchło wsszystko zależy od tego co chcesz osiągnąć

> 3) garbage collecting aby nie puchło bez powodu
> 4) kronikowaniu
> 

Chcesz trzymać kronikowanie w tym samym pliku? Marny pomysł nawet 
partycje przechowują to oddzielnie

> Innymi słowy internesuje mnie to "itd". Przykładowo, synchronizacja 
> międxzyprocesowa jest do ogarnięcia, ale idę o zaklad że zrobię to 
> niewydajnie.
> 

Pierwsze wersje będa napewno nie wydajne ale musisz zacząć coś pisać a 
potem to optymalizować bo inaczej się zamotasz

>> PS. Poszukaj w necie swego czasu byl dostępny opis FiieSystem Fat16 i 
>> może wtedy zrozumiesz różnice między formatem pliku a filesystem
> 
> Nie przypuszczam aby FAT obsługiwał poprawnie trim i GC. I nie wiem czy 
> można go używać bez licencji (ktoś wie czy MS jeszcze grozi paluszkiem?).

Trim jest to zwykle obciecie bajtów tyle to po pierwsze
GC nie znajdziesz w żadnym systemie plikow bo ono jest gdzie inidziej to 
po drugie
Po trzecie podałem przykład Fat16 zebys sobie zobaczył jak jest 
zbudowany a nie go używał

Pozdrawiam
J-23

On 06/04/2021 21:32, J-23 wrote:
> Rozwiązuje i to dużo problem w tym że tobie nawet się nie chce poszukać 
> źrodeł by zobaczyć jak to jest tam zrobione

Może dlatego, że wiem jak są zrobione.

> Bląd bo ja używam tego trywialnego kontenera do zbudowania "warstwy", 
> "formatu", "filesystem" do ktora pozwoli Ci zapisać co chcesz i operować 
> tym jak chcesz.

Zbudowanie warstwy zapisującej bloki jest *trywialne* w porównaniu ze 
zbudowaniem tego "formatu", jak go nazywasz.

> A biorąc Twoje wymagania pod uwage opisane w odrębnym poscie tego wątku 
> nie są one skomplikowane

Tak Ci się tylko wydaje.

>> W środku jest czarna dziura. W dodatku skomplikowana, którą nazywasz 
>> "formatem" - weź se napisz. No więc to nie jest trywialne.
> No i co tych plików nie możesz wpakować do tej struktury którą utworzysz?

Zabawny jesteś nie pojmując że to "wpakowanie do struktury" jest 
zagadnieniem nietrywialnym. Troche jak przeszkolak "Tatusiu, to nie 
możesz jutro zbudować tego domu? Przecież masz już rysunek."

>> To już rozwiązaniem nie jest plik z maszyny wirtualnej?
> Nie w 100% ale w 80% procentach masz w tym pliku gotowe roziwązanie 
> wystarczy je zgłębić

Zgłebić ten prosty translator bloków z trim? A co ja tam znajdę nadto, 
czego nie wiem?

>> Obawiam się że nie mieszam. Mogę był głupi, ale akurat na tym się 
>> trochę znam. Wbrew pozorom napisałem kilka rzeczy w życiu, były tem 
>> też proste filesystemy.
> Wiec co ci przeszkadza wykorzystać to doświadczenie lub nawet pokazać to 
> co zrobiles do tej pory (mam na mysli te male filesystem)

Nic mi nie przeszkadza (gdybym był głupi). Ale ponieważ z wiekiem rośnie 
pojmowanie swojej niewiedzy, wolałbym podeprzeć się opiniami kogoś kto 
ma większe pojęcie.

Niestety te "filesystemy" były też komercyjne. Ale to nic wielkiego, w 
zasadzie bez znaczenia.

>> Napisałem to kilka razy. Napiszę ponownie: aby utrzymać spójnośc 
>> danych. Na ten przykład wiele programów pakuje swoje małe pliczki do 
>> jednego ZIPa czy tar.gz, zmienia mu nazwę i masz .foo.
> Wiec z czym masz problem z upakowanienem tego, z wielodostępem?

To co napisałem już kilka razy: aby na tym pracować. Na ZIP nie da się 
pracować, wymaga wypakowania i ponownego spakowania za każdy razem, to 
storage a nie filesystem.

> Bo ja tak naprawdę widze jeden problem z wielodostępem bo wielodostęp 
> jest zależny od systemu plikow na jakim sie plik znajduje i to jedyny 
> problem jaki widze na teraz

Akurat od tego ani troche nie zależy. Cały ten filesystem może byc w RAM 
albo na kartach perforowanych, niewiel to zmienia. To gdzie będą 
zapisywane bloki jest zupełnie poza dyskusją.

>> To ja chce wiecej. Chce móc na tym pracować, a nie tylko używać jako 
>> storage.
> Od kiedy nie można pracować na "pliku"? Możesz go wczytywać fragmentami 
> możesz go wczytać w calosci (o ile ci starczy pamięci) i na nim pracować

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.

>> Polecam konsultację z mount -o loop pod Linuxem, może zauważysz, że 
>> *plik* mozna traktować jako nośnik filesystemu. Jego "format" staje 
>> się wtedy filesystemem wprost.
> A to kolego zależy już faktycznie od Filesystem a nie od mount. Twoj 
> Filesystem już i tak będzie leżał na jakimś systemie plików - chyba że 
> będziesz go zapisywał bezpośrednio na dysku (z pominięciem systemu 
> plików) w co wątpie

To gdzie będzie leżał jest kompletnie bez znaczenia. W przypadku unit 
testów będzie sobie leżał w char* foo;

>> 1) wielodostępie (a tym samym blokowaniu). Z watków (łatwe) i procesów 
>> (łomatko!)
 > Za to odpowiadać będzie system plików na którym będziesz trzymał swój
 > FileSystem

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?

Niby jak wielodostęp do rzeczywistego pliku ma mi pomóc w utrzymaniu 
spójności danych w *środku*, w wirtualnych plikach?

Jesli dalej nie pojmujesz, to zrób doświadczenie:

Wyobraż sobie plik który ma dwa bajty.

I kilka procesów, które realizują taki algorytm: czytają pierwszy bajt, 
podnoszą o jeden i zapisują, po czym czytaja drugi bajt, podnoszą o 
jeden i zapisują.

Starujesz od 0x0000

Kto ma zagwaratnować że po chwili w tym pliku, kazdy odczyt sekencyjny, 
bedzie zwracał dwa bajty o tych samych wartościach?

Czaisz bazę, gdzie możesz sobie wsadzić wielodostep na poziomie OSu?

> Tutaj zależy jak zorganizujesz usuwanie elementów bo można to zrobić tak 
> jak to robi np FB i będzie puchło a można usuwać konkretne bajty i nie 
> będzie puchło wsszystko zależy od tego co chcesz osiągnąć

Konkretne bajty można usuwać z pliku? Owszem, jest pojęcie "pliku z 
dziurami" na Unixach, ale to nie działa jak myslisz.

> 
>> 3) garbage collecting aby nie puchło bez powodu
>> 4) kronikowaniu
> Chcesz trzymać kronikowanie w tym samym pliku? Marny pomysł nawet 
> partycje przechowują to oddzielnie

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.

> Pierwsze wersje będa napewno nie wydajne ale musisz zacząć coś pisać a 
> potem to optymalizować bo inaczej się zamotasz

Bzdura.

>> Nie przypuszczam aby FAT obsługiwał poprawnie trim i GC. I nie wiem 
>> czy można go używać bez licencji (ktoś wie czy MS jeszcze grozi 
>> paluszkiem?).
> Trim jest to zwykle obciecie bajtów tyle to po pierwsze

Dziękujemy Kapitanie Obvious.

> GC nie znajdziesz w żadnym systemie plikow bo ono jest gdzie inidziej to 

Ojej!

> Po trzecie podałem przykład Fat16 zebys sobie zobaczył jak jest 
> zbudowany a nie go używał

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

On 06/04/2021 21:01, J-23 wrote:
>> No ale zrobili to GC na bazie czy nie zrobili? Twierdzisz że GC to 
>> tylko na pamięci, a tutaj banda nieświadomych świrów zrobiła na 
>> plikach. Bezczelni.
> Zwróć uwagę że GC odbywa sie podczas zupelnie oddzielnej operacji.

No ale zrobili czy nie?

> Tutaj projektaci w IB/FB nie przejmowali się tym na etapie tworzenia 
> struktury i ty też nie powinieneś

Łomatko...

>> Ja chce zamiast tego relokować sektory i trimować końcówkę pliku.
>> Niewielka różnica.
> I w czym widzisz problem? bo ja żadnego mozesz taki plik obciac o 
> określoną ilość bajtów i tyle

O tym że najpierw muszę przeallokować strukturę w środku. Pod rygorem 
wielodostepu i utrzymania spójności.

> Trzymaj się tematu bo odpływasz. Naprawde masz problem z zakodowaniem 
> tego co wypisałeś w punktach w formie klasy z metodą SaveToFile

To takie proste? Wystarczy nazwać klasą "SaveToFile" i nagle wózki 
dopisują kilkadziesiąt tysięcy lini kodu samodzielnie? WOW! Dzięki!

> i potem 
> odczytać w całości lub po fragmencie? Bo zacząłbym od tego i zobaczyłbym 
> gdzie leży problem? Tzn czy mam problemy wydajnościowe, z dostępem itp

No wiec tam nie leży. Mimo że dalej traktujesz mnie jak idiotę to musisz 
wiedzieć że ta apliakcja nie jest niedzielnym programikiem do robienia 
faktur z OpenPascalu. To deczko bardziej wymagający kawałek kodu i różne 
pomiary, analizy, doświadczenia i pomysły się już przewinęły. Powiedzmy, 
że nie przejmowałbym się wydajnością czytania bloków z pliku, nawet 
jesli po drodze jest warstwa translacji wirtualnego systemu plików.

W dniu 2021.04.07 o 08:48, heby pisze:
> On 06/04/2021 21:01, J-23 wrote:
> 
> No wiec tam nie leży. Mimo że dalej traktujesz mnie jak idiotę to musisz 
> wiedzieć że ta apliakcja nie jest niedzielnym programikiem do robienia 
> faktur z OpenPascalu. To deczko bardziej wymagający kawałek kodu i różne 
> pomiary, analizy, doświadczenia i pomysły się już przewinęły. Powiedzmy, 
> że nie przejmowałbym się wydajnością czytania bloków z pliku, nawet 
> jesli po drodze jest warstwa translacji wirtualnego systemu plików.

Argument z dupy bo nie ma nic wspolnego z tematem ty nie pojmujesz ze 
twoj system plików jest tak naprawdę zwykłym formatem ktory da sie czytać.

Pozdrawiam
J-23

On 07/04/2021 11:52, J-23 wrote:
> zwykłym formatem

No właśnie. Niepotrzebnie dyskutujemy, to tylko zwykły format, do 
napisania w każdym sklepie z formatami.

W dniu 2021.04.07 o 08:43, heby pisze:
> On 06/04/2021 21:32, J-23 wrote:
>> Rozwiązuje i to dużo problem w tym że tobie nawet się nie chce 
>> poszukać źrodeł by zobaczyć jak to jest tam zrobione
> 
> Może dlatego, że wiem jak są zrobione.

Po tym co piszesz widać że nie wiesz jak tam to jest zrobione.

> 
>> Bląd bo ja używam tego trywialnego kontenera do zbudowania "warstwy", 
>> "formatu", "filesystem" do ktora pozwoli Ci zapisać co chcesz i 
>> operować tym jak chcesz.
> 
> Zbudowanie warstwy zapisującej bloki jest *trywialne* w porównaniu ze 
> zbudowaniem tego "formatu", jak go nazywasz.
> 
>> A biorąc Twoje wymagania pod uwage opisane w odrębnym poscie tego 
>> wątku nie są one skomplikowane
> 
> Tak Ci się tylko wydaje.


Tak sie składa że na codzień pracuje na plikach które mają fizycznie 
ponad 100 GB i jakoś nie mam dylematow jak Ty

> 
>>> W środku jest czarna dziura. W dodatku skomplikowana, którą nazywasz 
>>> "formatem" - weź se napisz. No więc to nie jest trywialne.
>> No i co tych plików nie możesz wpakować do tej struktury którą utworzysz?
> 
> Zabawny jesteś nie pojmując że to "wpakowanie do struktury" jest 
> zagadnieniem nietrywialnym. Troche jak przeszkolak "Tatusiu, to nie 
> możesz jutro zbudować tego domu? Przecież masz już rysunek."


Problem w tym że ty próbujesz od nas czytających dowiedzieć się o 
rozwiązaniu ktore tylko ty znasz jego przeznaczenie. Sam niestety 
grzebierz za głębko ale sobie z tego sprawy nie zdajesz

> 
>>> To już rozwiązaniem nie jest plik z maszyny wirtualnej?
>> Nie w 100% ale w 80% procentach masz w tym pliku gotowe roziwązanie 
>> wystarczy je zgłębić
> 
> Zgłebić ten prosty translator bloków z trim? A co ja tam znajdę nadto, 
> czego nie wiem?
> 

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

>>> Obawiam się że nie mieszam. Mogę był głupi, ale akurat na tym się 
>>> trochę znam. Wbrew pozorom napisałem kilka rzeczy w życiu, były tem 
>>> też proste filesystemy.
>> Wiec co ci przeszkadza wykorzystać to doświadczenie lub nawet pokazać 
>> to co zrobiles do tej pory (mam na mysli te male filesystem)
> 
> Nic mi nie przeszkadza (gdybym był głupi). Ale ponieważ z wiekiem rośnie 
> pojmowanie swojej niewiedzy, wolałbym podeprzeć się opiniami kogoś kto 
> ma większe pojęcie.
> 
> Niestety te "filesystemy" były też komercyjne. Ale to nic wielkiego, w 
> zasadzie bez znaczenia.

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

> 
>>> Napisałem to kilka razy. Napiszę ponownie: aby utrzymać spójnośc 
>>> danych. Na ten przykład wiele programów pakuje swoje małe pliczki do 
>>> jednego ZIPa czy tar.gz, zmienia mu nazwę i masz .foo.
>> Wiec z czym masz problem z upakowanienem tego, z wielodostępem?
> 
> To co napisałem już kilka razy: aby na tym pracować. Na ZIP nie da się 
> pracować, wymaga wypakowania i ponownego spakowania za każdy razem, to 
> storage a nie filesystem.
> 
>> Bo ja tak naprawdę widze jeden problem z wielodostępem bo wielodostęp 
>> jest zależny od systemu plikow na jakim sie plik znajduje i to jedyny 
>> problem jaki widze na teraz
> 
> Akurat od tego ani troche nie zależy. Cały ten filesystem może byc w RAM 
> albo na kartach perforowanych, niewiel to zmienia. To gdzie będą 
> zapisywane bloki jest zupełnie poza dyskusją.
> 
>>> To ja chce wiecej. Chce móc na tym pracować, a nie tylko używać jako 
>>> storage.
>> Od kiedy nie można pracować na "pliku"? Możesz go wczytywać 
>> fragmentami możesz go wczytać w calosci (o ile ci starczy pamięci) i 
>> na nim pracować
> 
> 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

To czy coś jest plikiem lub katalogiem decyduje Filesystem

Gdzie podobno ty proste filesystemy pisales i tego nie wiesz - ciekawe.

>>> Polecam konsultację z mount -o loop pod Linuxem, może zauważysz, że 
>>> *plik* mozna traktować jako nośnik filesystemu. Jego "format" staje 
>>> się wtedy filesystemem wprost.
>> A to kolego zależy już faktycznie od Filesystem a nie od mount. Twoj 
>> Filesystem już i tak będzie leżał na jakimś systemie plików - chyba że 
>> będziesz go zapisywał bezpośrednio na dysku (z pominięciem systemu 
>> plików) w co wątpie
> 
> To gdzie będzie leżał jest kompletnie bez znaczenia. W przypadku unit 
> testów będzie sobie leżał w char* foo;
> 
>>> 1) wielodostępie (a tym samym blokowaniu). Z watków (łatwe) i 
>>> procesów (łomatko!)
>> Za to odpowiadać będzie system plików na którym będziesz trzymał swój
>> FileSystem
> 
> 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

> Niby jak wielodostęp do rzeczywistego pliku ma mi pomóc w utrzymaniu 
> spójności danych w *środku*, w wirtualnych plikach?
> 
> Jesli dalej nie pojmujesz, to zrób doświadczenie:
> 
> Wyobraż sobie plik który ma dwa bajty.
> 
> I kilka procesów, które realizują taki algorytm: czytają pierwszy bajt, 
> podnoszą o jeden i zapisują, po czym czytaja drugi bajt, podnoszą o 
> jeden i zapisują.
> 
> Starujesz od 0x0000
> 
> Kto ma zagwaratnować że po chwili w tym pliku, kazdy odczyt sekencyjny, 
> bedzie zwracał dwa bajty o tych samych wartościach? 


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

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.

A wiedza na czym to ma działać zmienia diametralnie podejsście do tego 
co chcesz

> 
> Czaisz bazę, gdzie możesz sobie wsadzić wielodostep na poziomie OSu?

Wlasnie nie wiem czego bo nie określiłeś na czym to ma działać

> 
>> Tutaj zależy jak zorganizujesz usuwanie elementów bo można to zrobić 
>> tak jak to robi np FB i będzie puchło a można usuwać konkretne bajty i 
>> nie będzie puchło wsszystko zależy od tego co chcesz osiągnąć
> 
> 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

> 
>>
>>> 3) garbage collecting aby nie puchło bez powodu
>>> 4) kronikowaniu
>> Chcesz trzymać kronikowanie w tym samym pliku? Marny pomysł nawet 
>> partycje przechowują to oddzielnie
> 
> 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

Bo teraz gadasz głupoty z rozpędu lub nie wiesz do czego te kroniki sluza
>> 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 :)

> 
>>> Nie przypuszczam aby FAT obsługiwał poprawnie trim i GC. I nie wiem 
>>> czy można go używać bez licencji (ktoś wie czy MS jeszcze grozi 
>>> paluszkiem?).
>> Trim jest to zwykle obciecie bajtów tyle to po pierwsze
> 
> Dziękujemy Kapitanie Obvious.
> 
>> GC nie znajdziesz w żadnym systemie plikow bo ono jest gdzie inidziej to 
> 
> Ojej!
> 
>> Po trzecie podałem przykład Fat16 zebys sobie zobaczył jak jest 
>> zbudowany a nie go używał
> 
> 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. A podobno to co 
Tworzysz to Filesystem wiec jak to jest?

Pozdrawiam
J-23

W dniu 2021.04.07 o 12:03, heby pisze:
> On 07/04/2021 11:52, J-23 wrote:
>> zwykłym formatem
> 
> No właśnie. Niepotrzebnie dyskutujemy, to tylko zwykły format, do 
> napisania w każdym sklepie z formatami.

Ty nie rozumiesz podstaw o których juz pisałem

Dla uproszczenia skupie się na dwóch elementach

co decyduje o tym co jest
a) katalogiem
b) plikiem

Wybierz sobie dowolny system plików i sprawdź.

Może wtedy pojmiesz że ty to musisz napisać sam lub wziąć to obadać na 
podstawie istniejących rozwiązań

Bo ty ciągle powtarzasz jedno że chcesz pracować na pliku, ktory będzie 
zachowywał się jak partycja i to jest zrozumiałe.

Nie zrozumiałe jest tylko to czego tak naprawdę szukasz bo wszystko 
czego potrzebujesz masz dostępne w postaci kodu a że tego jest dużo i 
dużo analizowania to inna bajka.

Pozdrawiam
J-23

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.

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

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?

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