Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > pl.comp.programming > #34341 > unrolled thread

Przenośny, uproszczony filesystem

Back to article view | Back to pl.comp.programming

Contents

  Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-01-14 13:31 +0100
    Re: Przenośny, uproszczony filesystem "M.M." <mmarszik@gmail.com> - 2021-02-05 10:42 -0800
      Re: Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-02-07 12:55 +0100
        Re: Przenośny, uproszczony filesystem "M.M." <mmarszik@gmail.com> - 2021-02-07 06:34 -0800
          Re: Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-02-07 19:04 +0100
            Re: Przenośny, uproszczony filesystem "M.M." <mmarszik@gmail.com> - 2021-02-07 10:35 -0800
            Re: Przenośny, uproszczony filesystem "M.M." <mmarszik@gmail.com> - 2021-02-07 11:03 -0800
              Re: Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-02-07 20:57 +0100
                Re: Przenośny, uproszczony filesystem "M.M." <mmarszik@gmail.com> - 2021-02-07 12:19 -0800
                  Re: Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-02-07 22:01 +0100
                    Re: Przenośny, uproszczony filesystem "M.M." <mmarszik@gmail.com> - 2021-02-07 13:53 -0800
                      Re: Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-02-08 07:39 +0100
                        Re: Przenośny, uproszczony filesystem "M.M." <mmarszik@gmail.com> - 2021-02-08 02:08 -0800
                          Re: Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-02-08 12:12 +0100
                            Re: Przenośny, uproszczony filesystem "M.M." <mmarszik@gmail.com> - 2021-02-08 05:24 -0800
                              Re: Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-02-08 14:57 +0100
                                Re: Przenośny, uproszczony filesystem "M.M." <mmarszik@gmail.com> - 2021-02-08 09:35 -0800
                                  Re: Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-02-08 18:41 +0100
                                    Re: Przenośny, uproszczony filesystem "M.M." <mmarszik@gmail.com> - 2021-02-08 10:47 -0800
                                    Re: Przenośny, uproszczony filesystem Piotr Chamera <piotr_chamera@poczta.onet.pl> - 2021-02-08 20:33 +0100
                                      Re: Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-02-08 20:35 +0100
    Re: Przenośny, uproszczony filesystem J-23 <Baczeklu@poczta.fm> - 2021-04-05 03:51 +0200
      Re: Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-04-05 11:30 +0200
        Re: Przenośny, uproszczony filesystem J-23 <Baczeklu@poczta.fm> - 2021-04-05 20:27 +0200
          Re: Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-04-05 23:04 +0200
            Re: Przenośny, uproszczony filesystem J-23 <Baczeklu@poczta.fm> - 2021-04-05 23:55 +0200
              Re: Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-04-06 10:58 +0200
                Re: Przenośny, uproszczony filesystem Mateusz Viste <mateusz@xyz.invalid> - 2021-04-06 11:22 +0200
                  Re: Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-04-06 12:03 +0200
                Re: Przenośny, uproszczony filesystem J-23 <Baczeklu@poczta.fm> - 2021-04-06 16:54 +0200
                  Re: Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-04-06 18:01 +0200
                    Re: Przenośny, uproszczony filesystem J-23 <Baczeklu@poczta.fm> - 2021-04-06 19:41 +0200
                      Re: Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-04-06 20:08 +0200
                        Re: Przenośny, uproszczony filesystem J-23 <Baczeklu@poczta.fm> - 2021-04-06 21:32 +0200
                          Re: Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-04-07 08:43 +0200
                            Re: Przenośny, uproszczony filesystem J-23 <Baczeklu@poczta.fm> - 2021-04-07 12:25 +0200
                              Re: Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-04-07 13:40 +0200
                                Re: Przenośny, uproszczony filesystem J-23 <Baczeklu@poczta.fm> - 2021-04-07 14:58 +0200
                                  Re: Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-04-07 15:21 +0200
                                    Re: Przenośny, uproszczony filesystem J-23 <Baczeklu@poczta.fm> - 2021-04-07 16:35 +0200
            Re: Przenośny, uproszczony filesystem J-23 <Baczeklu@poczta.fm> - 2021-04-06 00:31 +0200
              Re: Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-04-06 11:06 +0200
                Re: Przenośny, uproszczony filesystem J-23 <Baczeklu@poczta.fm> - 2021-04-06 17:08 +0200
                  Re: Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-04-06 18:12 +0200
                    Re: Przenośny, uproszczony filesystem J-23 <Baczeklu@poczta.fm> - 2021-04-06 19:57 +0200
                      Re: Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-04-06 20:17 +0200
                        Re: Przenośny, uproszczony filesystem J-23 <Baczeklu@poczta.fm> - 2021-04-06 21:01 +0200
                          Re: Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-04-07 08:48 +0200
                            Re: Przenośny, uproszczony filesystem J-23 <Baczeklu@poczta.fm> - 2021-04-07 11:52 +0200
                              Re: Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-04-07 12:03 +0200
                                Re: Przenośny, uproszczony filesystem J-23 <Baczeklu@poczta.fm> - 2021-04-07 12:42 +0200
                                  Re: Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-04-07 13:43 +0200
                                    Re: Przenośny, uproszczony filesystem J-23 <Baczeklu@poczta.fm> - 2021-04-07 14:29 +0200
                                      Re: Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-04-07 15:06 +0200
    Re: Przenośny, uproszczony filesystem Roman Tyczka <romantyczka@hate.you.spammer> - 2021-04-09 12:04 +0200
      Re: Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-04-09 13:42 +0200
        Re: Przenośny, uproszczony filesystem Roman Tyczka <romantyczka@hate.you.spammer> - 2021-04-09 22:55 +0200
          Re: Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-04-10 12:21 +0200

Page 1 of 3  [1] 2 3  Next page →

#34341 — Przenośny, uproszczony filesystem

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.

[toc] | [next] | [standalone]

#34354

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

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


Pozdrawiam

[toc] | [prev] | [next] | [standalone]

#34356

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

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

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

[toc] | [prev] | [next] | [standalone]

#34357

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

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

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

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

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

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

Pozdrawiam
 

[toc] | [prev] | [next] | [standalone]

#34359

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

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

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

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

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

[toc] | [prev] | [next] | [standalone]

#34360

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

[toc] | [prev] | [next] | [standalone]

#34361

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

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

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

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


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

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

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


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

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

Pozdrawiam

[toc] | [prev] | [next] | [standalone]

#34362

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

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

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

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

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

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

[toc] | [prev] | [next] | [standalone]

#34363

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

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


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

Uroki optymalizacji... coś za coś.

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

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

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

Pozdrawiam

[toc] | [prev] | [next] | [standalone]

#34364

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

Nie projektuje procesora.

>  Mutex
> koncepcyjnie to prosta sprawa

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

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

No wiec nie napylam tanzystorów.

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

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

[toc] | [prev] | [next] | [standalone]

#34365

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

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

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

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

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

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


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

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


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

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

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

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

Pozdrawiam

[toc] | [prev] | [next] | [standalone]

#34366

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

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

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

Na przykład na wirtualny plik w tym kontenerze.

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

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

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

> Transakcje nie są prostym lockiem

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

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

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

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

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

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

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

[toc] | [prev] | [next] | [standalone]

#34367

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

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

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

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


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

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

Też nie spotkałem się.


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

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


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

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

Ok.

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


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

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

Pozdrawiam

[toc] | [prev] | [next] | [standalone]

#34368

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

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

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

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

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

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

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

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

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

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

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

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

[toc] | [prev] | [next] | [standalone]

#34369

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

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

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


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

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

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

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

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

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

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

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

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

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


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

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

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

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

Pozdrawiam

[toc] | [prev] | [next] | [standalone]

#34370

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

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

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

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

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

O nie.

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

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

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

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

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

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

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

[toc] | [prev] | [next] | [standalone]

#34371

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

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

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

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



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

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

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

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

> O nie.

Przydatność zależy od konkretnego zastosowania. 



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

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


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

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


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

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


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

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

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


Pozdrawiam
 

[toc] | [prev] | [next] | [standalone]

#34372

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

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

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

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

[toc] | [prev] | [next] | [standalone]

#34373

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

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

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

Pozdrawiam

[toc] | [prev] | [next] | [standalone]

#34374

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

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

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

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

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

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

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

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

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | pl.comp.programming

csiph-web