eGospodarka.pl

eGospodarka.plGrupypl.comp.programming › Przenośny, uproszczony filesystem
Ilość wypowiedzi w tym wątku: 58

  • 1. Data: 2021-01-14 13:31:15
    Temat: Przenośny, uproszczony filesystem
    Od: heby <h...@p...onet.pl>

    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.


  • 2. Data: 2021-02-05 19:42:41
    Temat: Re: Przenośny, uproszczony filesystem
    Od: "M.M." <m...@g...com>

    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







  • 3. Data: 2021-02-07 12:55:34
    Temat: Re: Przenośny, uproszczony filesystem
    Od: heby <h...@p...onet.pl>

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


  • 4. Data: 2021-02-07 15:34:21
    Temat: Re: Przenośny, uproszczony filesystem
    Od: "M.M." <m...@g...com>

    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


  • 5. Data: 2021-02-07 19:04:28
    Temat: Re: Przenośny, uproszczony filesystem
    Od: heby <h...@p...onet.pl>

    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.


  • 6. Data: 2021-02-07 19:35:29
    Temat: Re: Przenośny, uproszczony filesystem
    Od: "M.M." <m...@g...com>

    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.


  • 7. Data: 2021-02-07 20:03:08
    Temat: Re: Przenośny, uproszczony filesystem
    Od: "M.M." <m...@g...com>

    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


  • 8. Data: 2021-02-07 20:57:42
    Temat: Re: Przenośny, uproszczony filesystem
    Od: heby <h...@p...onet.pl>

    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.


  • 9. Data: 2021-02-07 21:19:59
    Temat: Re: Przenośny, uproszczony filesystem
    Od: "M.M." <m...@g...com>

    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



  • 10. Data: 2021-02-07 22:01:17
    Temat: Re: Przenośny, uproszczony filesystem
    Od: heby <h...@p...onet.pl>

    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.

strony : [ 1 ] . 2 ... 6



Szukaj w grupach

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: