eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingPrzenośny, uproszczony filesystem › Re: Przenośny, uproszczony filesystem
  • Data: 2021-02-08 11:08:30
    Temat: Re: Przenośny, uproszczony filesystem
    Od: "M.M." <m...@g...com> szukaj wiadomości tego autora
    [ pokaż wszystkie nagłówki ]

    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=ubun
    tu&q=systemy+plik%C3%B3w+literatura

    Pozdrawiam


Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

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: