Discussion:
Przenośny, uproszczony filesystem
(Wiadomość utworzona zbyt dawno temu. Odpowiedź niemożliwa.)
heby
2021-01-14 12:31:15 UTC
Permalink
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.
M.M.
2021-02-05 18:42:41 UTC
Permalink
Post by heby
Cześć.
Poszukuje inspiracji a być może gotowca. Ale to trudno powiedzieć. A
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ń.
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?
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
heby
2021-02-07 11:55:34 UTC
Permalink
Post by M.M.
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ą.
M.M.
2021-02-07 14:34:21 UTC
Permalink
Post by heby
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
heby
2021-02-07 18:04:28 UTC
Permalink
Post by M.M.
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.
Post by M.M.
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.
M.M.
2021-02-07 18:35:29 UTC
Permalink
Post by heby
Post by M.M.
Takich kilka chaotycznych/zgrubnych i nie do końca przemyślanych wskazówek : By trzeba
zdefiniować rozmiar węzła,
1) jak realizuje sie kronikowanie - tak bardziej pod kątem teoretycznym
2) jak realizuej się wielodostep z wątków i locki w systemie.
Post by M.M.
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.
M.M.
2021-02-07 19:03:08 UTC
Permalink
Post by heby
Post by M.M.
Takich kilka chaotycznych/zgrubnych i nie do końca przemyślanych wskazówek : By trzeba
zdefiniować rozmiar węzła,
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.
Post by heby
2) jak realizuej się wielodostep z wątków i locki w systemie.
Z ciekawości zapytam, do czego potrzebujesz takiej wiedzy?
Post by heby
Post by M.M.
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.
Post by heby
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
heby
2021-02-07 19:57:42 UTC
Permalink
Post by M.M.
Post by heby
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.
Post by M.M.
Post by heby
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.
M.M.
2021-02-07 20:19:59 UTC
Permalink
Post by heby
Post by M.M.
Post by heby
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.
Post by heby
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ś.
Post by heby
Post by M.M.
Post by heby
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
heby
2021-02-07 21:01:17 UTC
Permalink
Post by M.M.
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.
Post by M.M.
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.
Post by M.M.
zliczanie ile wątków przeszło przez jakąś barierę. Ale jaką techniką trzeba napylić
tranzystory
No wiec nie napylam tanzystorów.
Post by M.M.
Post by heby
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.
M.M.
2021-02-07 21:53:31 UTC
Permalink
Post by heby
Post by M.M.
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?
Post by heby
Post by M.M.
Mutex
koncepcyjnie to prosta sprawa
Tu mutex powinien być na "fragment" filesystemu.
Tu czyli gdzie i dlaczego na fragment filesystemu? Co rozumiesz przez filesystem?
Post by heby
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.
Post by heby
Post by M.M.
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?
Post by heby
Post by M.M.
Post by heby
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.
Post by heby
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
heby
2021-02-08 06:39:31 UTC
Permalink
Post by M.M.
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.
Post by M.M.
Post by heby
Post by M.M.
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ą.
Post by M.M.
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.
Post by M.M.
Post by heby
Post by M.M.
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.
Post by M.M.
Post by heby
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".
Post by M.M.
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.
M.M.
2021-02-08 10:08:30 UTC
Permalink
Post by heby
Post by M.M.
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.
Post by heby
Post by M.M.
Post by heby
Post by M.M.
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.
Post by heby
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ą.
Post by M.M.
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ę.
Post by heby
Post by M.M.
Post by heby
Post by M.M.
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.
Post by heby
Post by M.M.
Post by heby
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.
Post by heby
Post by M.M.
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
heby
2021-02-08 11:12:26 UTC
Permalink
Post by M.M.
Post by heby
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.
Post by M.M.
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.
Post by M.M.
Post by heby
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.
Post by M.M.
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.
Post by M.M.
Post by heby
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.
M.M.
2021-02-08 13:24:56 UTC
Permalink
Post by heby
Post by M.M.
Post by heby
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.
Post by heby
Post by M.M.
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.
Post by heby
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ć.
Post by heby
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.
Post by heby
Post by M.M.
Post by heby
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.
Post by heby
Post by M.M.
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.
Post by M.M.
Post by heby
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
heby
2021-02-08 13:57:12 UTC
Permalink
Post by M.M.
Post by heby
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.
Post by M.M.
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.
Post by M.M.
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.
Post by M.M.
Post by heby
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.
Post by M.M.
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ć.
Post by M.M.
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...
M.M.
2021-02-08 17:35:02 UTC
Permalink
Post by heby
Post by heby
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.
Post by heby
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.
Post by heby
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.
Post by heby
Post by heby
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.
Post by heby
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.
Post by heby
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.
Post by heby
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
heby
2021-02-08 17:41:44 UTC
Permalink
Post by M.M.
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.
Post by M.M.
Post by heby
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.
M.M.
2021-02-08 18:47:46 UTC
Permalink
Post by heby
Post by M.M.
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.
Post by M.M.
Post by heby
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
Piotr Chamera
2021-02-08 19:33:14 UTC
Permalink
Post by heby
Post by M.M.
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”
heby
2021-02-08 19:35:11 UTC
Permalink
[ciach]
Dzieki.
J-23
2021-04-05 01:51:59 UTC
Permalink
Post by heby
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
heby
2021-04-05 09:30:12 UTC
Permalink
Post by J-23
Post by heby
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
Post by J-23
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.
Post by J-23
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.
Post by J-23
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 ;) ?
J-23
2021-04-05 18:27:33 UTC
Permalink
Post by heby
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
heby
2021-04-05 21:04:30 UTC
Permalink
Post by J-23
Post by heby
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.
Post by J-23
pytanie po co?
Zostało to wyjaśnione.
Post by J-23
Moim zdaniem sięgasz zbyt głęboko. To co opisujesz
według mnie da się prosto.
Więc jak?
Post by J-23
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.
Post by J-23
z Twojej strony z tego co napisałem bo coś chcesz stworzyć ale sam do
końca nie wiesz co
*DOSKONALE* wiem co.
Post by J-23
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?
Post by J-23
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ą.
Post by J-23
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ć.
Post by J-23
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.
Post by J-23
Tylko pytanie po co?
Odpowiedź padła w tym wątku.
Post by J-23
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.
Post by J-23
Zamiast wykorzystać już jakieś gotowe rozwiązanie
Zasugeruj jakie. Nie znajduje gotowych rozwiązań poza workaroudami jak
bloby w db.
Post by J-23
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.
J-23
2021-04-05 21:55:56 UTC
Permalink
Post by heby
Post by J-23
Post by heby
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 :)
Post by heby
Post by J-23
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
Post by heby
Post by J-23
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
Post by heby
Post by J-23
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.
Post by J-23
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
Post by heby
Post by J-23
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?
Post by J-23
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
Post by heby
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
Post by heby
Post by J-23
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
Post by heby
Post by J-23
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
Post by heby
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
Post by heby
Post by J-23
Tylko pytanie po co?
Odpowiedź padła w tym wątku.
Dopiero teraz :)
Post by heby
Post by J-23
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ć
Post by heby
Post by J-23
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
Post by heby
Post by J-23
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
heby
2021-04-06 08:58:17 UTC
Permalink
Post by J-23
Post by heby
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*.
Post by J-23
Post by heby
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.
Post by J-23
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?
Post by J-23
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.
Post by J-23
Post by heby
*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.
Post by J-23
Post by heby
Post by J-23
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.
Post by J-23
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ąć.
Post by J-23
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.
Post by J-23
Post by heby
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.
Post by J-23
Post by heby
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".
Post by J-23
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.
Post by J-23
Post by heby
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.
Post by J-23
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?
Post by J-23
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.
Post by J-23
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.
Post by J-23
Moja rada poczytaj o tym jak się konstruję formaty plików
A jak się konstruuje formaty plików? Jest jakiś poradnik do tego?
Post by J-23
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.
Post by J-23
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.
Mateusz Viste
2021-04-06 09:22:15 UTC
Permalink
Post by heby
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
heby
2021-04-06 10:03:05 UTC
Permalink
Post by Mateusz Viste
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ą.
J-23
2021-04-06 14:54:46 UTC
Permalink
Post by heby
Post by J-23
Post by heby
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ąć
Post by heby
Unikam wtedy bałaganu w postaci katalogu z plikami, w których user może
coś uszkodzić. Praktyka pokazała że to *krytyczne*.
Post by J-23
Post by heby
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)
Post by heby
Post by J-23
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
Post by heby
Post by J-23
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?
Post by heby
Post by J-23
Post by heby
*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.
Post by J-23
Post by heby
Post by J-23
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?
Post by heby
Post by J-23
Napisałem już w pierwszym moim poście że musisz zbudować odpowiedni
format pliku
Pacjet: Panie doktorze co dalej?
Doktur: Powinien pan wyzdrowieć, od tego proszę zacząć.
Post by J-23
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
Post by heby
Post by J-23
Post by heby
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.
Post by J-23
Post by heby
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.
Post by heby
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
Post by heby
Post by J-23
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.
Post by J-23
Post by heby
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
Post by heby
Post by J-23
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
Post by heby
Post by J-23
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.
Post by J-23
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
Post by heby
Post by J-23
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
Post by heby
Post by J-23
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
heby
2021-04-06 16:01:04 UTC
Permalink
Post by J-23
Rozumiem doskonale i próbuje dać Ci podstawowe kroki od czego zacząć
Niezupełnie, podpowadasz na razie banały.
Post by J-23
Post by heby
Omijasz podstawowy problem. Strukturę tego pliki "binarnego". Skupiasz
się na trzecirzędnych duprelach.
Taka strukture musisz sobie napisać
Tak, dokładnie.
Post by J-23
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)?
Post by J-23
Post by heby
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.
Post by J-23
Post by heby
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 ;)
Post by J-23
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?
Post by J-23
Post by heby
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.
Post by J-23
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ć.
Post by J-23
Post by heby
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.
Post by J-23
Post by heby
To ma być filesystem, bo w API mowa o plikach a bie blokach na dysku.
o jakim api mówisz?
Moim.
Post by J-23
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.
Post by J-23
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".
Post by J-23
Post by heby
Post by J-23
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.
Post by J-23
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ć.
Post by J-23
Post by heby
Post by J-23
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.
Post by J-23
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.
J-23
2021-04-06 17:41:28 UTC
Permalink
Post by heby
Post by J-23
Rozumiem doskonale i próbuje dać Ci podstawowe kroki od czego zacząć
Niezupełnie, podpowadasz na razie banały.
Post by J-23
Post by heby
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.
Post by heby
Post by J-23
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
Post by heby
Post by J-23
Post by heby
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.
Post by J-23
Post by heby
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
Post by heby
Post by J-23
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
Post by heby
Post by J-23
Post by heby
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ć
Post by heby
Post by J-23
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
Post by heby
Post by J-23
Post by heby
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
Post by heby
Post by J-23
Post by heby
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 :)
Post by heby
Post by J-23
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ś
Post by heby
Post by J-23
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?
Post by heby
Post by J-23
Post by heby
Post by J-23
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.
Post by heby
Post by J-23
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ć
Post by heby
Post by J-23
Post by heby
Post by J-23
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.
Post by J-23
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
heby
2021-04-06 18:08:03 UTC
Permalink
Post by J-23
Post by heby
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.
Post by J-23
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".
Post by J-23
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.
Post by J-23
Post by heby
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ę".
Post by J-23
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ą.
Post by J-23
Post by heby
Moim.
O to dowiadujemy się o czymś zupelnie nowym :)
Nic dziwnego. Było to opisane w pierwszych paru linijkach pierwotnego postu.
Post by J-23
Post by heby
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.
Post by J-23
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.
Post by J-23
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.
Post by J-23
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.
Post by J-23
Jakbyś chwile pomyślał to byś się zastanowił i napisał nam wszystkim
czego ty tak naprawdę potrzebujesz. Bo Filesystem to
- Katalogi
Zbędne.
Post by J-23
- pliki
Tak.
Post by J-23
- uprawnienia
Zbędne.
Post by J-23
- dodawanie/usuwanie pliku/katalogu
Tak, bez katalogu.
Post by J-23
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.
Post by J-23
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?).
J-23
2021-04-06 19:32:48 UTC
Permalink
Post by heby
Post by J-23
Post by heby
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
Post by heby
Post by J-23
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".
Post by J-23
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
Post by heby
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?
Post by heby
Post by J-23
Post by heby
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ę".
Post by J-23
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ć
Post by heby
Po pierwsze, niekoniecze szukam gotowca. Literatura też się nada.
Po drugie, nie doceniasz ludzi, którzy tutaj pisują.
Post by J-23
Post by heby
Moim.
O to dowiadujemy się o czymś zupelnie nowym :)
Nic dziwnego. Było to opisane w pierwszych paru linijkach pierwotnego postu.
Post by J-23
Post by heby
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)
Post by heby
Post by J-23
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.
Post by J-23
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
Post by heby
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ć
Post by heby
Post by J-23
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
Post by heby
Post by J-23
Jakbyś chwile pomyślał to byś się zastanowił i napisał nam wszystkim
czego ty tak naprawdę potrzebujesz. Bo Filesystem to
- Katalogi
Zbędne.
Post by J-23
- pliki
Tak.
Post by J-23
- uprawnienia
Zbędne.
Post by J-23
- dodawanie/usuwanie pliku/katalogu
Tak, bez katalogu.
Post by J-23
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ć
Post by heby
Niestety w itd znajduje się mięsko. O ile powyższe punkty mogę sobie
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
Post by heby
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ąć
Post by heby
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
Post by heby
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
Post by heby
Post by J-23
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
heby
2021-04-07 06:43:07 UTC
Permalink
Post by J-23
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.
Post by J-23
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.
Post by J-23
A biorąc Twoje wymagania pod uwage opisane w odrębnym poscie tego wątku
nie są one skomplikowane
Tak Ci się tylko wydaje.
Post by J-23
Post by heby
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."
Post by J-23
Post by heby
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?
Post by J-23
Post by heby
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.
Post by J-23
Post by heby
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.
Post by J-23
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ą.
Post by J-23
Post by heby
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.
Post by J-23
Post by heby
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;
Post by J-23
Post by heby
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?
Post by J-23
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.
Post by J-23
Post by heby
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.
Post by J-23
Pierwsze wersje będa napewno nie wydajne ale musisz zacząć coś pisać a
potem to optymalizować bo inaczej się zamotasz
Bzdura.
Post by J-23
Post by heby
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.
Post by J-23
GC nie znajdziesz w żadnym systemie plikow bo ono jest gdzie inidziej to
Ojej!
Post by J-23
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ć.
J-23
2021-04-07 10:25:14 UTC
Permalink
Post by heby
Post by J-23
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.
Post by heby
Post by J-23
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.
Post by J-23
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
Post by heby
Post by J-23
Post by heby
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
Post by heby
Post by J-23
Post by heby
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?
Post by heby
Post by J-23
Post by heby
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 :)
Post by heby
Post by J-23
Post by heby
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.
Post by J-23
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ą.
Post by J-23
Post by heby
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.
Post by heby
Post by J-23
Post by heby
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;
Post by J-23
Post by heby
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
Post by heby
Niby jak wielodostęp do rzeczywistego pliku ma mi pomóc w utrzymaniu
spójności danych w *środku*, w wirtualnych plikach?
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
Post by heby
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ć
Post by heby
Post by J-23
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
Post by heby
Post by J-23
Post by heby
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
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
Post by heby
Post by J-23
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 :)
Post by heby
Post by J-23
Post by heby
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.
Post by J-23
GC nie znajdziesz w żadnym systemie plikow bo ono jest gdzie inidziej to
Ojej!
Post by J-23
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
heby
2021-04-07 11:40:03 UTC
Permalink
Post by J-23
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
Post by J-23
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ą.
Post by J-23
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.
Post by J-23
Post by heby
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.
Post by J-23
Post by heby
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.
Post by J-23
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.
Post by J-23
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.
Post by J-23
Post by heby
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
Post by J-23
Post by heby
Zabawne. Bo tak nie jest. Mój plik fizyczny to taka "partycja", tylko
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.
Post by J-23
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ć.
Post by J-23
Post by heby
Post by J-23
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ąć.
Post by J-23
Post by heby
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.
J-23
2021-04-07 12:58:26 UTC
Permalink
Post by heby
Post by J-23
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.
Post by heby
Post by J-23
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
Post by heby
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ł
Post by heby
Post by J-23
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
Post by heby
Post by J-23
Post by heby
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
Post by heby
Post by J-23
Post by heby
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.
Post by J-23
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
Post by heby
Post by J-23
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
Post by heby
Post by J-23
Post by heby
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ę
Post by heby
Post by J-23
Post by heby
Zabawne. Bo tak nie jest. Mój plik fizyczny to taka "partycja", tylko
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
Post by heby
Post by J-23
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
Post by heby
Post by J-23
Post by heby
Post by J-23
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
Post by heby
Post by J-23
Post by heby
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
heby
2021-04-07 13:21:20 UTC
Permalink
Post by J-23
Post by heby
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.
Post by J-23
A czym jest dysk?
Czymkolwiek co ma stan potrafiący chwilę przetrwać.
Post by J-23
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.
Post by J-23
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.
Post by J-23
Post by heby
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.
Post by J-23
Nie rozumiesz że Filesystem to tylko struktura
O, to akurat rozumiem.
Post by J-23
Post by heby
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.
Post by J-23
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.
Post by J-23
Dlatego jest bardzo ważne co w tym pliku twoim ma być ty tylko
odpowiadasz pliki a to troche ogolna odp
Wystarczająca.
Post by J-23
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.
Post by J-23
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.
Post by J-23
Post by heby
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.
Post by J-23
Post by heby
Post by J-23
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.
Post by J-23
Post by heby
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"
Post by J-23
Zablysnąłeś wiedzą a ja na to powiem że mało wiesz
Wiem, że wiesz, że wiem.
Post by J-23
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?
J-23
2021-04-07 14:35:27 UTC
Permalink
Post by heby
Post by J-23
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
J-23
2021-04-05 22:31:43 UTC
Permalink
Post by heby
Post by J-23
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
heby
2021-04-06 09:06:31 UTC
Permalink
Post by J-23
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.
Post by J-23
Mieszasz pojęcia nie rozumiesz co to jest format pliku.
Najprawdopodobniej żyje w innej rzeczywistości.
Post by J-23
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?
Post by J-23
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.
Post by J-23
2. Trim - to nawet pozostawie bez komentarza
To źle, bo ten trim jest krytycznie istotny aby całość miała sens.
Post by J-23
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ć.
Post by J-23
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.
J-23
2021-04-06 15:08:23 UTC
Permalink
Post by heby
...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
heby
2021-04-06 16:12:07 UTC
Permalink
Post by J-23
Post by heby
...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?
Post by J-23
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.
Post by J-23
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.
Post by J-23
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.
J-23
2021-04-06 17:57:06 UTC
Permalink
Post by heby
Ś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.
Post by heby
Post by J-23
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
Post by heby
Post by J-23
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.
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
Post by heby
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
heby
2021-04-06 18:17:40 UTC
Permalink
Post by J-23
Post by heby
Ś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.
Post by J-23
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.
Post by J-23
Post by heby
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.
Post by J-23
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.
Post by J-23
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.
Post by J-23
Post by heby
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ę".
Post by J-23
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.
Post by J-23
Post by heby
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.
J-23
2021-04-06 19:01:49 UTC
Permalink
Post by heby
Post by J-23
Post by heby
Ś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ś
Post by heby
Post by J-23
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
Post by heby
Post by J-23
Post by heby
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
Post by heby
Post by J-23
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ć
Post by heby
Post by J-23
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.
Post by heby
Post by J-23
Post by heby
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
heby
2021-04-07 06:48:30 UTC
Permalink
Post by J-23
Post by heby
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?
Post by J-23
Tutaj projektaci w IB/FB nie przejmowali się tym na etapie tworzenia
struktury i ty też nie powinieneś
Łomatko...
Post by J-23
Post by heby
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.
Post by J-23
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!
Post by J-23
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.
J-23
2021-04-07 09:52:34 UTC
Permalink
Post by heby
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
heby
2021-04-07 10:03:53 UTC
Permalink
Post by J-23
zwykłym formatem
No właśnie. Niepotrzebnie dyskutujemy, to tylko zwykły format, do
napisania w każdym sklepie z formatami.
J-23
2021-04-07 10:42:07 UTC
Permalink
Post by heby
Post by J-23
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
heby
2021-04-07 11:43:25 UTC
Permalink
Post by J-23
co decyduje o tym co jest
a) katalogiem
b) plikiem
Nic, bo nie potrzebuję katalogów.
Post by J-23
Może wtedy pojmiesz że ty to musisz napisać sam
To akurat pojmuję.
Post by J-23
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.
Dokładnie. Przykładowo nie wiem po co ludzie projektują rakiety skoro w
około jest pełno protonów, neutronów i elektronów którze można tylko
właściwie poskładać i wychodzi rakieta. Weźmy na przykład takie
procedury. Dzięki nim można napisać AI do rakiety! Naprawdę, nie sposób
przecenić takich rad.
J-23
2021-04-07 12:29:13 UTC
Permalink
Post by heby
Post by J-23
co decyduje o tym co jest
a) katalogiem
b) plikiem
Nic, bo nie potrzebuję katalogów.
Ty to co nazywasz katalogiem jest zbiorem bajtów zrozum to wreszcie. Bo
jak widać tego nie pojmujesz
Post by heby
Post by J-23
Może wtedy pojmiesz że ty to musisz napisać sam
To akurat pojmuję.
Nie pojmujesz bo szukasz gotowego rozwiązania. Tym samym pomijasz info
ze masz rozwiązanie.

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

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

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

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

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

Brak jest podstawowej informacji co ty chcesz robić

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

Napisales pracować na plikach czyli co z nimi robić

1. Obcinać/sklejać modyfikować a jeśli modyfikować to jak?

2. Uruchamiać te pliki

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

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

Domyslam sie że nie ale wypisanie 4 czy 5 punktow ktore ująłeś w którymś
poscie i pracowanie na tym to mi do zrobienia czegoś takiego wystarczą
strumienie. Kwestia tylko co rozumiemy przez prace na plikach o ktorej
nie wspomniales ani slowem
Post by heby
Post by J-23
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.
Dokładnie. Przykładowo nie wiem po co ludzie projektują rakiety skoro w
około jest pełno protonów, neutronów i elektronów którze można tylko
właściwie poskładać i wychodzi rakieta. Weźmy na przykład takie
procedury. Dzięki nim można napisać AI do rakiety! Naprawdę, nie sposób
przecenić takich rad.
Widzisz i sam nie wiesz co czytasz. Bo dla mnie to nie jest poskładanie
protonow i neutronow a zdobycie doświadczenia na bazie tego co ktos
stworzył. Ty probujesz dostać gotowy pomysł i adoptować go do swoich
potrzeb a tak to nie dziala.

Pozdrawiam
heby
2021-04-07 13:06:23 UTC
Permalink
Post by J-23
Post by heby
Nic, bo nie potrzebuję katalogów.
Ty to co nazywasz katalogiem jest zbiorem bajtów zrozum to wreszcie. Bo
jak widać tego nie pojmujesz
Nie pojmuję, bo ich nie potrzebuje.
Post by J-23
Twoim rozwiązaniem jest wziąć adoptować system plikow i go przenieść na
to by pracował na pliku a nie na fizycznym dysku
Wow. Prawdziwy postęp w Twoim pojmowaniu, zaczynasz czaić bazę. Tak,
mógłbym tak zrobić.

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

O ile mogę napisać warstwę trimującą pod spodem, to mam nadzieje że
redukujac swoją ignorancję w temacie "jak się pisze filesystemy" może
się okazać że to jest zrabialne za jednym razem z fs.
Post by J-23
Tylko ty nie pojmujesz tego że to wiąże sie ze zbudowaniem odpowiedniej
struktury
:D Znowu ta mistyczna struktura. Zdardź wreszcie jak ona wygląda.
Post by J-23
A no gdzie szukać informacji jak to zbudować - skoro potrzebujesz
funkcjonalności pliku to zobacz jak on jest zbudowany np na FAT czy
innym systemie wyciągnij wnioski i pisz
Ale FAT jest gówno wart.
Post by J-23
Dlaczego piszę że to moim zdaniem system pliktów to jest dużo na wyrost
bo to co potrzebujesz da się zrobić w dużo mniej skomplikowany sposob
niz Filesystem
I oczywisćie *jeszcze* nie ujawniłeś tego światu. Ale czekamy.
Post by J-23
Zrob prosty test zapakuj dwa pliki w jeden tylko nie zipem :) i co nie
da się na nich pracować - da tylko musisz wiedzieć jakie to są pliki i
co chcesz z nich wyciągnąć a ty poki co nic nie wspominasz jakiego typu
sa pliki ktore będziesz pakował czy znasz format tych plikow?
Genialne. Zlepmy te wszystkie pliki w OS, na ch... komu filesystemy.

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

I określ co to jest "zapakuj".
Post by J-23
Brak jest podstawowej informacji co ty chcesz robić
Jak się nie czyta postów, szczególnie pierwszego, to faktycznie brak.
Post by J-23
Zapakować pliki w jeden to wystarczą strumienie i taką informacje żeś
dostal ode mnie
Genialne. Dowolny problem można rozwiązać poprzez zignorowanie trudnych
aspektów a nastepnie podając trywialne rozwiązanie.

Zrobisz karierę w polityce.
Post by J-23
Napisales pracować na plikach czyli co z nimi robić
1. Obcinać/sklejać modyfikować a jeśli modyfikować to jak?
Normalnie. file.writeBytes( buf, count );
Post by J-23
2. Uruchamiać te pliki
Nie.
Post by J-23
moge jeszcze dużo rzeczy wypisać o których nawet słowkiem nie
wspomnialłeś a są istotne
Wspomniałem o wszystm co istotne.
Post by J-23
Pytałem w którymś poście budujesz symulator dysku - cisza brak odp
To nie symulator dysku. Symulator dysku da się zrobić jako dd
if=/dev/zero of=dysk bs=512 count=1000. Działa znakomicie.
Post by J-23
Domyslam sie że nie ale wypisanie 4 czy 5 punktow ktore ująłeś w którymś
poscie i pracowanie na tym to mi do zrobienia czegoś takiego wystarczą
strumienie.
Nie wystarczą.
Post by J-23
Kwestia tylko co rozumiemy przez prace na plikach o ktorej
nie wspomniales ani slowem
Padało to w wątku niezliczoną ilość razy.
Post by J-23
Widzisz i sam nie wiesz co czytasz. Bo dla mnie to nie jest poskładanie
protonow i neutronow a zdobycie doświadczenia na bazie tego co ktos
stworzył. Ty probujesz dostać gotowy pomysł i adoptować go do swoich
potrzeb a tak to nie dziala.
Dokładnie. A jak świeci słońce, to jest dzień. Można mnie cytować.
Roman Tyczka
2021-04-09 10:04:08 UTC
Permalink
Post by heby
Dzięki temu mogę w jednym pliku trzymac w środku wiele plików,
bezustannie je czytajac i zmieniając. Ułatwi mi to pracę, ponieważ pliki
te są trzymane razem, user nie może nic w nich popsuć, nie muszę
bezustannie pakować/rozpakować jak robi np. OpenOffice (u nich
kontenerem jest packer). Od razu gotowe do pracy.
Może SQLite?
--
pzdr
Roman
heby
2021-04-09 11:42:03 UTC
Permalink
Post by Roman Tyczka
Może SQLite?
Mam tak w celach zatkania czymś interfejsu. Ale SQLite jest absurdalnie
powolne przy czytaniu random access pliów i jedyna metoda synchronizacji
mutithread jest *chyba* implementowana dość naiwnie sądząc po zachowaniu.

Tak czy inaczej taka zatyczka na API się nie sprawdza za dobrze,
produkcyjnie. W testach ok, jako mock.
Roman Tyczka
2021-04-09 20:55:41 UTC
Permalink
Post by heby
Mam tak w celach zatkania czymś interfejsu. Ale SQLite jest absurdalnie
powolne przy czytaniu random access pliów i jedyna metoda synchronizacji
mutithread jest *chyba* implementowana dość naiwnie sądząc po zachowaniu.
Tak czy inaczej taka zatyczka na API się nie sprawdza za dobrze,
produkcyjnie. W testach ok, jako mock.
To idźmy dalej tym tropem, może Firebird Embedded? :-)
--
pzdr
Roman
heby
2021-04-10 10:21:30 UTC
Permalink
Post by Roman Tyczka
Post by heby
Tak czy inaczej taka zatyczka na API się nie sprawdza za dobrze,
produkcyjnie. W testach ok, jako mock.
To idźmy dalej tym tropem, może Firebird Embedded? :-)
Wiesz, ja nie tylko chce funkcjonalność, przydała by się też prędkośc.
mmap by się przydał w zasadzie. W przypadku sprytnie rozwiązanego
filesystemu można doprowadzić do sytuacji gdy rawdata z filesystemu jest
widziane wprost w pamięci, w miarę liniowo.

Loading...