eGospodarka.pl
eGospodarka.pl poleca

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

  • 31. Data: 2021-04-06 12:03:05
    Temat: Re: Przenośny, uproszczony filesystem
    Od: heby <h...@p...onet.pl>

    On 06/04/2021 11:22, Mateusz Viste wrote:
    > 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ą.


  • 32. Data: 2021-04-06 16:54:46
    Temat: Re: Przenośny, uproszczony filesystem
    Od: J-23 <B...@p...fm>

    W dniu 2021.04.06 o 10:58, heby pisze:
    > On 05/04/2021 23:55, J-23 wrote:
    >>> 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ąć

    > Unikam wtedy bałaganu w postaci katalogu z plikami, w których user może
    > coś uszkodzić. Praktyka pokazała że to *krytyczne*.
    >
    >>> 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)

    >> 2. Wykorzystując formaty tj VDI
    >> https://www.arysontechnologies.com/blog/how-to-open-
    vdi-file/#:~:text=VDI%20or%20Virtual%20Drive%20Forma
    t,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

    >
    >> 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?

    >>> *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.
    >
    >>>> 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?

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

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

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

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

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

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


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


  • 33. Data: 2021-04-06 17:08:23
    Temat: Re: Przenośny, uproszczony filesystem
    Od: J-23 <B...@p...fm>

    W dniu 2021.04.06 o 11:06, heby pisze:
    >
    > ...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


  • 34. Data: 2021-04-06 18:01:04
    Temat: Re: Przenośny, uproszczony filesystem
    Od: heby <h...@p...onet.pl>

    On 06/04/2021 16:54, J-23 wrote:
    > Rozumiem doskonale i próbuje dać Ci podstawowe kroki od czego zacząć

    Niezupełnie, podpowadasz na razie banały.

    >> Omijasz podstawowy problem. Strukturę tego pliki "binarnego". Skupiasz
    >> się na trzecirzędnych duprelach.
    > Taka strukture musisz sobie napisać

    Tak, dokładnie.

    > 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)?

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

    >> 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 ;)

    > 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?

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

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

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

    >> To ma być filesystem, bo w API mowa o plikach a bie blokach na dysku.
    > o jakim api mówisz?

    Moim.

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

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

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

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

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

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


  • 35. Data: 2021-04-06 18:12:07
    Temat: Re: Przenośny, uproszczony filesystem
    Od: heby <h...@p...onet.pl>

    On 06/04/2021 17:08, J-23 wrote:
    >> ...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/clear
    path-mcp-18.0/86000759-621/section-000017440.html

    https://www.firebirdsql.org/pdfmanual/html/gfix-hous
    ekeeping.html

    https://docs.oracle.com/cd/E23943_01/admin.1111/e100
    29/gar_coll.htm#OIDAG089

    Świat jest pełen świrów, nie?

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

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

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


  • 36. Data: 2021-04-06 19:41:28
    Temat: Re: Przenośny, uproszczony filesystem
    Od: J-23 <B...@p...fm>

    W dniu 2021.04.06 o 18:01, heby pisze:
    > On 06/04/2021 16:54, J-23 wrote:
    >> Rozumiem doskonale i próbuje dać Ci podstawowe kroki od czego zacząć
    >
    > Niezupełnie, podpowadasz na razie banały.
    >
    >>> 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.

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

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

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

    >>> 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ć


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

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

    >
    >>> 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 :)

    >
    >> 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ś
    >> 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?

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

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


  • 37. Data: 2021-04-06 19:57:06
    Temat: Re: Przenośny, uproszczony filesystem
    Od: J-23 <B...@p...fm>

    W dniu 2021.04.06 o 18:12, heby pisze:
    > On 06/04/2021 17:08, J-23 wrote:
    > Ś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.
    >
    >> 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

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

    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


    > 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


  • 38. Data: 2021-04-06 20:08:03
    Temat: Re: Przenośny, uproszczony filesystem
    Od: heby <h...@p...onet.pl>

    On 06/04/2021 19:41, J-23 wrote:
    >> 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.

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

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

    >> 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ę".

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

    >> Moim.
    > O to dowiadujemy się o czymś zupelnie nowym :)

    Nic dziwnego. Było to opisane w pierwszych paru linijkach pierwotnego postu.

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

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

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

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

    > Jakbyś chwile pomyślał to byś się zastanowił i napisał nam wszystkim
    > czego ty tak naprawdę potrzebujesz. Bo Filesystem to
    > - Katalogi

    Zbędne.

    > - pliki

    Tak.

    > - uprawnienia

    Zbędne.

    > - dodawanie/usuwanie pliku/katalogu

    Tak, bez katalogu.

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

    > 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?).


  • 39. Data: 2021-04-06 20:17:40
    Temat: Re: Przenośny, uproszczony filesystem
    Od: heby <h...@p...onet.pl>

    On 06/04/2021 19:57, J-23 wrote:
    >> Ś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.

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

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

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

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

    >> 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
    > 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ę".

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

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


  • 40. Data: 2021-04-06 21:01:49
    Temat: Re: Przenośny, uproszczony filesystem
    Od: J-23 <B...@p...fm>

    W dniu 2021.04.06 o 20:17, heby pisze:
    > On 06/04/2021 19:57, J-23 wrote:
    >>> Ś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ś

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

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

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

strony : 1 ... 3 . [ 4 ] . 5 . 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: