eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingPrzenośny, uproszczony filesystem › Re: Przenośny, uproszczony filesystem
  • Path: news-archive.icm.edu.pl!news.icm.edu.pl!fu-berlin.de!3.eu.feeder.erje.net!feede
    r.erje.net!feeder1.feed.usenet.farm!feed.usenet.farm!news.uzoreto.com!fdc2.netn
    ews.com!news-out.netnews.com!newsin.alt.net!fdcspool2.netnews.com!news-out.netn
    ews.com!news.alt.net!fdc3.netnews.com!peer04.ams1!peer.ams1.xlned.com!news.xlne
    d.com!peer03.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!newsfee
    d.neostrada.pl!unt-exc-02.news.neostrada.pl!unt-spo-a-02.news.neostrada.pl!news
    .neostrada.pl.POSTED!not-for-mail
    Subject: Re: Przenośny, uproszczony filesystem
    Newsgroups: pl.comp.programming
    References: <rtpdik$cge$1@dont-email.me> <606a6d41$0$522$65785112@news.neostrada.pl>
    <s4elb8$cni$3@dont-email.me> <606b5698$0$542$65785112@news.neostrada.pl>
    <s4fu13$s6b$1@dont-email.me> <606b876c$0$517$65785112@news.neostrada.pl>
    <s4h7rd$n3v$1@dont-email.me> <606c7635$0$529$65785112@news.neostrada.pl>
    <s4i0k5$p2p$1@dont-email.me> <606c9d47$0$522$65785112@news.neostrada.pl>
    <s4i82d$l12$1@dont-email.me> <606cb760$0$512$65785112@news.neostrada.pl>
    <s4jka0$6mq$1@dont-email.me>
    From: J-23 <B...@p...fm>
    Date: Wed, 7 Apr 2021 12:25:14 +0200
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
    Thunderbird/78.9.0
    MIME-Version: 1.0
    In-Reply-To: <s4jka0$6mq$1@dont-email.me>
    Content-Type: text/plain; charset=utf-8; format=flowed
    Content-Language: pl
    Content-Transfer-Encoding: 8bit
    Lines: 225
    Message-ID: <606d8889$0$505$65785112@news.neostrada.pl>
    Organization: Telekomunikacja Polska
    NNTP-Posting-Host: 95.160.17.234
    X-Trace: 1617791114 unt-rea-b-01.news.neostrada.pl 505 95.160.17.234:51893
    X-Complaints-To: a...@n...neostrada.pl
    X-Received-Bytes: 10317
    Xref: news-archive.icm.edu.pl pl.comp.programming:215449
    [ ukryj nagłówki ]

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

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

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


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

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


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

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

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

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

    To że byly komercyjne nie znaczy że wiedza ci po nich nie pozostała i
    nie możesz na tej wiedzy bazować. To co napisałeś brzmi "wiem jak dziaja
    filesystem ale nie moge tej wiedzy wykorzystać bo korzystalem z niej
    komercyjnie w projekcie" Smiech na sali :)

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

    Nie rozumiesz że to co ty nazywasz plikiem to dla pamieci jest takim
    samym blokiem pamieci jak wszystko inne

    To czy coś jest plikiem lub katalogiem decyduje Filesystem

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

    >>> Polecam konsultację z mount -o loop pod Linuxem, może zauważysz, że
    >>> *plik* mozna traktować jako nośnik filesystemu. Jego "format" staje
    >>> się wtedy filesystemem wprost.
    >> A to kolego zależy już faktycznie od Filesystem a nie od mount. Twoj
    >> Filesystem już i tak będzie leżał na jakimś systemie plików - chyba że
    >> będziesz go zapisywał bezpośrednio na dysku (z pominięciem systemu
    >> plików) w co wątpie
    >
    > To gdzie będzie leżał jest kompletnie bez znaczenia. W przypadku unit
    > testów będzie sobie leżał w char* foo;
    >
    >>> 1) wielodostępie (a tym samym blokowaniu). Z watków (łatwe) i
    >>> procesów (łomatko!)
    >> Za to odpowiadać będzie system plików na którym będziesz trzymał swój
    >> FileSystem
    >
    > Widać że nie masz sladu pojmowania o czym mowa. Wyobraź sobie
    > std::vector i dwa wątki. Czyje zadanie jest zrobić synchronizacje?
    > Kontrolera pamięci, który nei ma pojęcia o atomowości operacji, czy
    > programista?
    >

    Widać masz za małe doświadczenie na wątkach... trudno nie będe Ci tego
    tlumaczył bo znowu nie zrozumiesz i stwierdzisz że nie o tym mowie co ty
    uważasz

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


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

    Zastanów się i odpowiedz na jakim to ma środowisku działać bo raz
    piszesz że nie ma to większego znaczenia a drugi razem piszesz o
    operacji na wątkach.

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

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

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

    >
    >> Tutaj zależy jak zorganizujesz usuwanie elementów bo można to zrobić
    >> tak jak to robi np FB i będzie puchło a można usuwać konkretne bajty i
    >> nie będzie puchło wsszystko zależy od tego co chcesz osiągnąć
    >
    > Konkretne bajty można usuwać z pliku? Owszem, jest pojęcie "pliku z
    > dziurami" na Unixach, ale to nie działa jak myslisz.


    To działa jak myśle tylko tyle że sama operacja trim nie zalatwia ci
    sprawy jak ty myslisz tutaj są potrzebne dodatkowe operacje o ktorych ty
    nie zdajesz sobie sprawy

    >
    >>
    >>> 3) garbage collecting aby nie puchło bez powodu
    >>> 4) kronikowaniu
    >> Chcesz trzymać kronikowanie w tym samym pliku? Marny pomysł nawet
    >> partycje przechowują to oddzielnie
    >
    > Zabawne. Bo tak nie jest. Mój plik fizyczny to taka "partycja", tylko że
    > zamiast bycia kawałkiem dysku, jest całym plikiem. I jeszcze raz:
    > kronika trzymana jest w środku partycji. Przynajmniej w popularnych fs
    > które znam.
    >

    Trzymana na partycji. Jesteś pewien? Otóż takie pytanie to po co te
    kroniki są i co w wypadku uszkodzenia partycji? Pomyśl chwile

    Bo teraz gadasz głupoty z rozpędu lub nie wiesz do czego te kroniki sluza
    >> Pierwsze wersje będa napewno nie wydajne ale musisz zacząć coś pisać a
    >> potem to optymalizować bo inaczej się zamotasz
    >
    > Bzdura.

    A to Ciekawe od ręki wiesz ze to co piszesz jest super optymalne.
    Gratuluje :)

    >
    >>> Nie przypuszczam aby FAT obsługiwał poprawnie trim i GC. I nie wiem
    >>> czy można go używać bez licencji (ktoś wie czy MS jeszcze grozi
    >>> paluszkiem?).
    >> Trim jest to zwykle obciecie bajtów tyle to po pierwsze
    >
    > Dziękujemy Kapitanie Obvious.
    >
    >> GC nie znajdziesz w żadnym systemie plikow bo ono jest gdzie inidziej to
    >
    > Ojej!
    >
    >> Po trzecie podałem przykład Fat16 zebys sobie zobaczył jak jest
    >> zbudowany a nie go używał
    >
    > No ale ja wiem jak jest zbudowany. Nijak to nie rozwiązuje tych
    > problemów z twojego zakresu "itd" które tak usilnie starasz się ignorować.


    Dziwne nagle Filesystem nie rozwiązuje tego co chcesz. A podobno to co
    Tworzysz to Filesystem wiec jak to jest?

    Pozdrawiam
    J-23

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: