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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#34375

On 08/02/2021 20:33, Piotr Chamera wrote:
> [ciach]

Dzieki.

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

#34428

W dniu 2021.01.14 o 13:31, heby pisze:
> Cześć.
> 
> Coś w ten deseń, czyli to ja dostaczam abstrakcje robiącą I/O na 
> poziomie block/cluster a kod realizuje wysokopoziomowe operacje plikowe.
> 

Ty musisz napisać własny format pliku. Tylko tyle i aż tyle. System 
plików to zupełnie inna para butów.

Nie wiem w czym to docelowo będziesz pisał ale do tej operacji wystarczy 
Ci znajomość Strumieni i przemyślany sposób jak to upakować wszystko.

Dla uproszczenia zrób sobie każdy element pliku (Formatu pliku) w 
oddzielnej klasie będzie ci łatwiej okiełznać strukturę w późniejszym 
etapie przy takim podejściu

Pozdrawiam
J-23

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

#34429

On 05/04/2021 03:51, J-23 wrote:
>> Coś w ten deseń, czyli to ja dostaczam abstrakcje robiącą I/O na 
>> poziomie block/cluster a kod realizuje wysokopoziomowe operacje plikowe.
> Ty musisz napisać własny format pliku.

Dziekuję, to odkrywcze :D

> Tylko tyle i aż tyle. System 
> plików to zupełnie inna para butów.

A ja myślałem że tam jest cała esencja.

> Nie wiem w czym to docelowo będziesz pisał ale do tej operacji wystarczy 
> Ci znajomość Strumieni i przemyślany sposób jak to upakować wszystko.

O to przemyślenie chodzi. Strumienie ogarniam. Ba, ograniam nawet random 
access.

> Dla uproszczenia zrób sobie każdy element pliku (Formatu pliku) w 
> oddzielnej klasie będzie ci łatwiej okiełznać strukturę w późniejszym 
> etapie przy takim podejściu

Genialne.

Jesteś pewny że wiesz o czym mówisz ;) ?

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

#34431

W dniu 2021.04.05 o 11:30, heby pisze:
> Jesteś pewny że wiesz o czym mówisz ;) ?

Widać po twoich postach w tym wątku że próbujesz robić pewne rzeczy do 
okola pytanie po co? Moim zdaniem sięgasz zbyt głęboko. To co opisujesz 
według mnie da się prosto.

Słowa typu "ogarniam nawet random access" jest nieudaną próbą szyderstwa 
z Twojej strony z tego co napisałem bo coś chcesz stworzyć ale sam do 
końca nie wiesz co to ma być ale napewno nie będzie to nawet "wirtualny 
filesystem" jak to sam nazwałeś

Chcesz budować Filesystem to pochwal się jak masz to ogarnięte do tej 
pory lub podejrzyj jak to jest budowane np w kodzie open source 
przykładów w sieci jest sporo.

Popraw mnie jeśli się myle ale twoja próbka kodu ma za zadanie (posłużę 
się twoim nazewnictwem)

1. Utworzyć FileSystem
2. Zapisać jakieś dane
3. Wysłać do urządzenia

Tylko pytanie po co?

Niby coś tam wyjaśniasz niżej ale ja nadal nie widzę po tych 
wyjaśnieniach powodu budowania własnego Filesystem

Zamiast wykorzystać już jakieś gotowe rozwiązanie

W tym co starasz się zbudować widzę sens grzebania w postaci nauki jak 
działają Systemy plików skoro to jest twoim celem to ok

Ale jeśli twoim celem jest budowanie systemu plików by upakować kilka 
plików w jedną strukturę jest pozbawione sensu bo to obecne systemy 
plików robią bez problemu

Pozdrawiam
J-23

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

#34432

On 05/04/2021 20:27, J-23 wrote:
>> Jesteś pewny że wiesz o czym mówisz ;) ?
> Widać po twoich postach w tym wątku że próbujesz robić pewne rzeczy do 
> okola

Tak, nie jest do zdecydowanie następna apliakcja do fakturowania.

> pytanie po co?

Zostało to wyjaśnione.

> Moim zdaniem sięgasz zbyt głęboko. To co opisujesz 
> według mnie da się prosto.

Więc jak?

> Słowa typu "ogarniam nawet random access"

Nie, to jest zwrócenie uwagi że "strumieniami" tego się nie ogarnia. To 
się ogarnia random access na rzeczywistym pliku. Razem z trim i kilkoma 
sztuczkami jak garbage collecting czy kompaktacja.

> z Twojej strony z tego co napisałem bo coś chcesz stworzyć ale sam do 
> końca nie wiesz co

*DOSKONALE* wiem co.

> to ma być ale napewno nie będzie to nawet "wirtualny 
> filesystem" jak to sam nazwałeś

Możesz się podeprzeć jakimś powodem, dlaczego to nie będzie wirtualny 
filesystem?

> Chcesz budować Filesystem to pochwal się jak masz to ogarnięte do tej 
> pory

Poczytaj wątek. Mam możliwosć schowania tego za abstrackją i aktualnie 
używam database. Ale database jest marną emulacją.

> lub podejrzyj jak to jest budowane np w kodzie open source 
> przykładów w sieci jest sporo.

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

> Popraw mnie jeśli się myle ale twoja próbka kodu ma za zadanie (posłużę 
> się twoim nazewnictwem)
> 1. Utworzyć FileSystem
> 2. Zapisać jakieś dane
> 3. Wysłać do urządzenia

Nie.

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.

Mała uwaga: to nie to samo co zamontowanie ext4 na loop. To ma być 
dynamicznie zmieniające rozmiar pliku rzeczywistego.

Najbliższy koncept z tej okolicy to np. qcow2.

> Tylko pytanie po co?

Odpowiedź padła w tym wątku.

> Niby coś tam wyjaśniasz niżej ale ja nadal nie widzę po tych 
> wyjaśnieniach powodu budowania własnego Filesystem

Bo nie przeczytałeś uważnie.

> Zamiast wykorzystać już jakieś gotowe rozwiązanie

Zasugeruj jakie. Nie znajduje gotowych rozwiązań poza workaroudami jak 
bloby w db.

> Ale jeśli twoim celem jest budowanie systemu plików by upakować kilka 
> plików w jedną strukturę jest pozbawione sensu bo to obecne systemy 
> plików robią bez problemu

Interesujące, podrzuć jakiś filesystem który pakuje pliki do jednego 
pliku i pozwala na ich dynamiczne używanie jednoczesnie kompaktując plik 
fizyczny.

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

#34433

W dniu 2021.04.05 o 23:04, heby pisze:
> On 05/04/2021 20:27, J-23 wrote:
>>> Jesteś pewny że wiesz o czym mówisz ;) ?
>> Widać po twoich postach w tym wątku że próbujesz robić pewne rzeczy do 
>> okola
> 
> Tak, nie jest do zdecydowanie następna apliakcja do fakturowania.

Aplikacje do fakturowania są proste a i tak większość działa w "dziwny" 
sposób bo co program to inne podejście :)
> 
>> pytanie po co?
> 
> Zostało to wyjaśnione.

Nie zostało to jednoznacznie wyjaśnione nawet osoba która dużo 
dyskutowała z Tobą w tym wątku stwierdziła że cieżko się rozmawia bo nie 
odpowiadasz na pytania
> 
>> Moim zdaniem sięgasz zbyt głęboko. To co opisujesz według mnie da się 
>> prosto.
> 
> Więc jak?
> 

Możesz to zrobić na co najmniej dwa sposoby
1. Korzystając ze strumieni i pliku binarnego
2. Wykorzystując formaty tj VDI

https://www.arysontechnologies.com/blog/how-to-open-vdi-file/#:~:text=VDI%20or%20Virtual%20Drive%20Format,Windows%20and%20other%20operating%20systems.

wiele innych jest tego sporo tylko ta opcja druga jest moim zdaniem w 
Twoim przypadku na "wyrost"

Dostęp do źrodeł masz opisy formatu znajdziesz też w sieci

>> Słowa typu "ogarniam nawet random access"
> 
> Nie, to jest zwrócenie uwagi że "strumieniami" tego się nie ogarnia. To 
> się ogarnia random access na rzeczywistym pliku. Razem z trim i kilkoma 
> sztuczkami jak garbage collecting czy kompaktacja.
> 
>> z Twojej strony z tego co napisałem bo coś chcesz stworzyć ale sam do 
>> końca nie wiesz co
> 
> *DOSKONALE* wiem co.


Bez szyderstwa. Napisz więcej co to ma robić bo mam wrażenie że 
strzelasz z armaty do wróbla

> 
>> to ma być ale napewno nie będzie to nawet "wirtualny filesystem" jak 
>> to sam nazwałeś
> 
> Możesz się podeprzeć jakimś powodem, dlaczego to nie będzie wirtualny 
> filesystem?
> 
>> 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

Napisałem już w pierwszym moim poście że musisz zbudować odpowiedni 
format pliku

Nawet przywołane przeze mnie VDI jest formatem pliku a nie systemem plików

> 
> Poczytaj wątek. Mam możliwosć schowania tego za abstrackją i aktualnie 
> używam database. Ale database jest marną emulacją.
> 

Po co ci Database? Armata na wróbla chociaż podejrzewam że będzie i tak 
bardziej wydajna niż to co stworzysz przynajmniej w pierwszych wersjach

>> lub podejrzyj jak to jest budowane np w kodzie open source przykładów 
>> w sieci jest sporo.
> 
> 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 bo 
System plików będzie faktycznie mocno zagmatwany bo ty potrzebujesz 20% 
tego co w systemie plików jest zawarte

>> Popraw mnie jeśli się myle ale twoja próbka kodu ma za zadanie 
>> (posłużę się twoim nazewnictwem)
>> 1. Utworzyć FileSystem
>> 2. Zapisać jakieś dane
>> 3. Wysłać do urządzenia
> 
> Nie.
> 
> 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ć

Strumienie nie dadzą rady w momencie gdy potrzebujesz z tego wycisnąć 
max wydajności

> 
> Mała uwaga: to nie to samo co zamontowanie ext4 na loop. To ma być 
> dynamicznie zmieniające rozmiar pliku rzeczywistego.
> 
> Najbliższy koncept z tej okolicy to np. qcow2.

https://formats.kaitai.io/vdi/java.html
> 
>> Tylko pytanie po co?
> 
> Odpowiedź padła w tym wątku.
> 

Dopiero teraz :)

>> Niby coś tam wyjaśniasz niżej ale ja nadal nie widzę po tych 
>> wyjaśnieniach powodu budowania własnego Filesystem
> 
> Bo nie przeczytałeś uważnie.

Przeczytałem tylko dopiero w odpowiedzi do mnie napisałeś to w jasny 
sposób ale nie ma o co się spierać
> 
>> Zamiast wykorzystać już jakieś gotowe rozwiązanie
> 
> Zasugeruj jakie. Nie znajduje gotowych rozwiązań poza workaroudami jak 
> bloby w db.
> 


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.

Moim zdaniem błędnie się zasugerowałeś że to ma być FileSystem

>> Ale jeśli twoim celem jest budowanie systemu plików by upakować kilka 
>> plików w jedną strukturę jest pozbawione sensu bo to obecne systemy 
>> plików robią bez problemu
> 
> Interesujące, podrzuć jakiś filesystem który pakuje pliki do jednego 
> pliku i pozwala na ich dynamiczne używanie jednoczesnie kompaktując plik 
> fizyczny.

wspomniany tu przeze mnie VDI to robi ale mam wrażenie że ty i tak tego 
nie potrzebujesz.

Moja rada poczytaj o tym jak się konstruję formaty plików i odejść od 
myślenia (na tym etapie) od tego że to jest system plików

Pytanie czy da się strumieniami twoim zdaniem zapakować kilka plików do 
jednego pliku?

Zadaje to pytanie nie po by się z Ciebie nabijać tylko po to by 
zrozumieć czemu sądzisz ze pliki typu qcow2/vdi są systemami plików.



Pozdrawiam
J-23

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

#34437

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

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.

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

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

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

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

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

Niejak nie pomagają mi w wyższej warstwie abstrackji typu "jak trzymać 
pliki w tym pliku".

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

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

> Moja rada poczytaj o tym jak się konstruję formaty plików

A jak się konstruuje formaty plików? Jest jakiś poradnik do tego?

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

> Zadaje to pytanie nie po by się z Ciebie nabijać tylko po to by 
> zrozumieć czemu sądzisz ze pliki typu qcow2/vdi są systemami plików.

Nie sądzę tak.

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

#34439

2021-04-06 o 10:58 +0200, heby napisał:
> 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ć.

Pewno umiesz korzystać z wyszukiwarki tak samo jak ja i już to
widziałeś, ale jeśli nie... Być może warte przejrzenia, bo z opisu
brzmi jak dokładnie to, czego szukasz.

https://code.google.com/archive/p/whefs/

"similar to conventional archives (e.g. zip files), except that this
library provides random-access read/write support to the filesystem via
an API similar to the conventional fopen(), fread(), fwrite() and
friends."

Mateusz

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

#34440

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

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

#34441

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%20Format,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

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

#34443

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.

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

#34446

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

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

#34448

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

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

#34451

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

Rozwiązuje i to dużo problem w tym że tobie nawet się nie chce poszukać 
źrodeł by zobaczyć jak to jest tam zrobione

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

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.

A biorąc Twoje wymagania pod uwage opisane w odrębnym poscie tego wątku 
nie są one skomplikowane

> 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 i co tych plików nie możesz wpakować do tej struktury którą utworzysz?

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

Nie w 100% ale w 80% procentach masz w tym pliku gotowe roziwązanie 
wystarczy je zgłębić
> 
> 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.
> 

Wiec co ci przeszkadza wykorzystać to doświadczenie lub nawet pokazać to 
co zrobiles do tej pory (mam na mysli te male filesystem)

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

Wiec z czym masz problem z upakowanienem tego, z wielodostępem?

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

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

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

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

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

To co jest plikiem a katalogiem to decyduje o tym znacznik w systemie plików

Skoro tworzysz strukture od zera to co za problem taki znacznik zrobić

> 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!)
Za to odpowiadać będzie system plików na którym będziesz trzymał swój 
FileSystem
> 2) trim, aby nie puchło bez powodu

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

> 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

> Innymi słowy internesuje mnie to "itd". Przykładowo, synchronizacja 
> międxzyprocesowa jest do ogarnięcia, ale idę o zaklad że zrobię to 
> niewydajnie.
> 

Pierwsze wersje będa napewno nie wydajne ale musisz zacząć coś pisać a 
potem to optymalizować bo inaczej się zamotasz

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

Trim jest to zwykle obciecie bajtów tyle to po pierwsze
GC nie znajdziesz w żadnym systemie plikow bo ono jest gdzie inidziej to 
po drugie
Po trzecie podałem przykład Fat16 zebys sobie zobaczył jak jest 
zbudowany a nie go używał

Pozdrawiam
J-23

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

#34453

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.

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

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

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

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

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

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

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?

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

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

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

> Pierwsze wersje będa napewno nie wydajne ale musisz zacząć coś pisać a 
> potem to optymalizować bo inaczej się zamotasz

Bzdura.

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

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

#34457

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

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

#34459

On 07/04/2021 12:25, J-23 wrote:
> Tak sie składa że na codzień pracuje na plikach które mają fizycznie 
> ponad 100 GB i jakoś nie mam dylematow jak Ty

Otóż to.
- Jakie Pan ma kwalifikacje na lekarza?
- Żyje od 40 lat i dobrze mi to wychodzi

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

Tam są wie rzeczy: struktura zapisu bloków symulowanego dysk tak, aby 
plik mógł rosnąc i redukować dynamicznie.

To załatwia VM.

I jest nastepna warstwa, to filesystem w systemie gościa.

Maszyna ma w nosie co gość robi z emulowanym dyskiem i jaki ma na nim 
filesystem. Ona tylko emuluje urzdzenie blokowe.

Innymi słowy maszyna wirtualna zajmuje sie tą łatwijeszą częscią.

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

Nie rozmuiesz. Prosty FS mogę sobie napisać. Pliki, duperele.

Prawdziwe ciekawoski kryją się w lockach, wielodostepie, kronikowaniu, 
GC i trim, translacji bloków w tle.

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

I ma takie same problemy jak trzymanie pliku ZIP w pamięci i operowanie 
na nim w realtime. ZIPy to nie filesystemy tylko storage. Pakuje się raz 
i koniec.

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

No więc synchronizacje std::vector rozwiązuje kontroler pamięci czy 
algrotym programu? Analogia wielodostępu do pliku wręcz idealna.

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

Ale nie odpowiedziłeś na pytanie. Kto gwarantuje spójnośc danych w 
pliku, jesli dorywaja się do niego dwa procesy na raz. Mówje o spójności 
tego mitycznego "formatu" który ma byc rozwiązaniem wszelakich problemów.

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

Struktura ma być odporna na wielodostęp. Inaczej: dowolna operacja na 
pliku wykonana w procesie A ba być widoczna spójnie w procesie B. 
Gwarantuje to *prawie* każdy filesystem.

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

:D

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

Nic. Do kosza. Kronikwanie nie słuzy do ratowania dupy w przypadku padu 
fizycznego dyku/partycji. Pomyliłeś z RAID.

> Bo teraz gadasz głupoty z rozpędu lub nie wiesz do czego te kroniki sluza

Wydaje mi się że wiem dostatecznie. Podpowiem Ci: do poprawiania 
miękkich błedów, takich jak nieoczekiwane znikniecie zasilania. Dzięki 
kronikom można okreslić jakiś poziom pewności, że sekwencyjny zapis 
zadziałał w przewidywalny sposób, a nie wynikajacy z przypadku ułożenia 
cache dysku lub tego że flash nie zdążył się na czas skasować.

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

Zabieranie się za robotę a potem "optymalizowane" uważam za żałosne 
podejście studenta na zaliczenie. Najpier należy zdobyć wiedzę, potem 
pracować wiedząc co czyniąć.

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

To proste, mistrzu. Twój plik z maszyny wirtualnej to nie filesystem. 
Więc nie rozwiązuje problemów. Twoje "zrób se pliki" nie rozwiązują 
problemów, bo magia jest w "itd" które zgrabnie pomijasz mocą swojej 
ignorancji.

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

#34462

W dniu 2021.04.07 o 13:40, heby pisze:
> On 07/04/2021 12:25, J-23 wrote:
>> Tak sie składa że na codzień pracuje na plikach które mają fizycznie 
>> ponad 100 GB i jakoś nie mam dylematow jak Ty
> 
> Otóż to.
> - Jakie Pan ma kwalifikacje na lekarza?
> - Żyje od 40 lat i dobrze mi to wychodzi
> 

Co to wnosi do rozmowy - nic.

>> To znajdziesz jak w 80% napisać taką strukture ale podobno znasz ten 
>> format wiec jak to jest? Znasz czy nie?
> 
> Tam są wie rzeczy: struktura zapisu bloków symulowanego dysk tak, aby 
> plik mógł rosnąc i redukować dynamicznie.
> 
> To załatwia VM.
> 
> I jest nastepna warstwa, to filesystem w systemie gościa.
> 
> Maszyna ma w nosie co gość robi z emulowanym dyskiem i jaki ma na nim 
> filesystem. Ona tylko emuluje urzdzenie blokowe.

A czym jest dysk? Ze tak zapytam bo może inaczej rozumiemy urządzenia 
blokowe

> 
> Innymi słowy maszyna wirtualna zajmuje sie tą łatwijeszą częscią.


Tak ale skąd czerpie info właśnie z tego pliku co tlumacze ci byś tam 
zajrzał

> 
>> 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 :)
> 
> Nie rozmuiesz. Prosty FS mogę sobie napisać. Pliki, duperele.
> 
> Prawdziwe ciekawoski kryją się w lockach, wielodostepie, kronikowaniu, 
> GC i trim, translacji bloków w tle.

Czemu tego nie sprawdzisz w innych Filesystemach chociać juz po 
ciekawostkach widać że to wykracza po za tą tematyke ale ty tego nie 
rozumiesz (Nie rozumiesz że Filesystem to tylko struktura) reszta jest 
gdzie indziej

> 
>>> 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
> 
> I ma takie same problemy jak trzymanie pliku ZIP w pamięci i operowanie 
> na nim w realtime. ZIPy to nie filesystemy tylko storage. Pakuje się raz 
> i koniec.
> 

Masz uraz do ZIPa że tak sie na nie uparłeś znam kupe innych rozszerzeń 
np bin ktore przechowywują inne pliki (poslugując się twoim tokiem 
rozumowania)

mam 3 obrazy zapisane w pliku bin i teraz zagadka jak do obrazka numer 2 
dodać kwiatek? Ty masz z tym problem ja nie mam problemu znająć 
zawartość bin by do obrazka nr 2 dodać kwiatek

Dlatego jest bardzo ważne co w tym pliku twoim ma być ty tylko 
odpowiadasz pliki a to troche ogolna odp

>>> 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
> 
> No więc synchronizacje std::vector rozwiązuje kontroler pamięci czy 
> algrotym programu? Analogia wielodostępu do pliku wręcz idealna.
> 
>> Znowu kłania się brak wiedzy o wątkach
> 
> Ale nie odpowiedziłeś na pytanie. Kto gwarantuje spójnośc danych w 
> pliku, jesli dorywaja się do niego dwa procesy na raz. Mówje o spójności 
> tego mitycznego "formatu" który ma byc rozwiązaniem wszelakich problemów.


Od kiedy Filesystm jest gwarantem spójności pliku? Są narzedzia do tego 
FS nic o spojnosci pliku nie wie
> 
>> 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.
> 
> Struktura ma być odporna na wielodostęp. Inaczej: dowolna operacja na 
> pliku wykonana w procesie A ba być widoczna spójnie w procesie B. 
> Gwarantuje to *prawie* każdy filesystem.
> 

Pokaż jakiś przykład bo pierwsze słysze że Filesystem oodpowiada za 
spojność - jaką spójność masz na mysli bo moze znowu mowisz o czymś co 
zupelnie inaczej się nazywa

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

No wlasnie tylko tyle można zrobić z twoją próbą zbudowania czegokolwiek 
- uśmiechnąć się

> 
>>> 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
> 
> Nic. Do kosza. Kronikwanie nie słuzy do ratowania dupy w przypadku padu 
> fizycznego dyku/partycji. Pomyliłeś z RAID.
> 

Wpisz "kroniki" w google a dowiesz się po co powstały bo tego nie wiesz.

Inna bajka że co FS są inaczej implementowane

>> Bo teraz gadasz głupoty z rozpędu lub nie wiesz do czego te kroniki sluza
> 
> Wydaje mi się że wiem dostatecznie. Podpowiem Ci: do poprawiania 
> miękkich błedów, takich jak nieoczekiwane znikniecie zasilania. Dzięki 
> kronikom można okreslić jakiś poziom pewności, że sekwencyjny zapis 
> zadziałał w przewidywalny sposób, a nie wynikajacy z przypadku ułożenia 
> cache dysku lub tego że flash nie zdążył się na czas skasować.
> 

Zablysnąłeś wiedzą a ja na to powiem że mało wiesz

>>>> 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 :)
> 
> Zabieranie się za robotę a potem "optymalizowane" uważam za żałosne 
> podejście studenta na zaliczenie. Najpier należy zdobyć wiedzę, potem 
> pracować wiedząc co czyniąć.

Ty nie zbierasz ty szukasz pomysłu który adoptujesz do wlasnego roziązania

> 
>>> 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.
> 
> To proste, mistrzu. Twój plik z maszyny wirtualnej to nie filesystem. 
> Więc nie rozwiązuje problemów. Twoje "zrób se pliki" nie rozwiązują 
> problemów, bo magia jest w "itd" które zgrabnie pomijasz mocą swojej 
> ignorancji.

Ty pomijasz więcej niż ci sie wydaje ale cóż nie ja mam problem ale ty. 
Ja akurat pracuje na czymś podobnym co chcesz osiągnąć - zbudowałem to 
od zera wzorująć się na FAT32 i ntfs-3g i wlasnie VDI no ale co ja tam 
wiem według ciebie to jest za mało.

Pozdrawiam

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

#34464

On 07/04/2021 14:58, J-23 wrote:
>> Otóż to.
>> - Jakie Pan ma kwalifikacje na lekarza?
>> - Żyje od 40 lat i dobrze mi to wychodzi
> Co to wnosi do rozmowy - nic.

Tak jak i cała reszta tych dywagacji, przeciez ja ciągnę tą dyskusję z 
powodów sportowych.

> A czym jest dysk?

Czymkolwiek co ma stan potrafiący chwilę przetrwać.

> Ze tak zapytam bo może inaczej rozumiemy urządzenia 
> blokowe

Rozumiemy tak samo. Rozumiemy jako disc[blockIndex]=block.

Pod spodem może być stacja dysków Atari 1050, jeśli to ma znaczenie.

> Tak ale skąd czerpie info właśnie z tego pliku co tlumacze ci byś tam 
> zajrzał

Ale tam nic nie ma poza tranaslacją bloków.

>> Prawdziwe ciekawoski kryją się w lockach, wielodostepie, kronikowaniu, 
>> GC i trim, translacji bloków w tle.
> Czemu tego nie sprawdzisz w innych Filesystemach

Ponieważ dano to zrobiłem. Wnioski są takie że optymalizacje są na tyle 
głebokie i rozległe, że traci się obraz i skrajnie utrudnia analizę. Na 
ten przykład przegladałem ext4. Bez dokumentacji nie byłem w stanie się 
w tym poruszac, z dokumentacją byłem w stanie pojąć 10% całości.

> Nie rozumiesz że Filesystem to tylko struktura

O, to akurat rozumiem.

>> operowanie na nim w realtime. ZIPy to nie filesystemy tylko storage. 
>> Pakuje się raz i koniec.
> Masz uraz do ZIPa że tak sie na nie uparłeś znam kupe innych rozszerzeń 
> np bin ktore przechowywują inne pliki (poslugując się twoim tokiem 
> rozumowania)

I one pozwalają na dynamiczną modyfikację swojej zawartości z 
trimowaniem i wielodostępem? Wow.

> mam 3 obrazy zapisane w pliku bin i teraz zagadka jak do obrazka numer 2 
> dodać kwiatek?

To łatwe. Proponuje trudniejsze: jak dodać czwarty obrazek z kwiatkiem 
pomiędzy pierwszy i drugi.

> Dlatego jest bardzo ważne co w tym pliku twoim ma być ty tylko 
> odpowiadasz pliki a to troche ogolna odp

Wystarczająca.

> Od kiedy Filesystm jest gwarantem spójności pliku?

Od czasu posiadania kroniki. Dane zapiywane są albo w całości jakiejś 
jednostki albo nie. Są również albo zapisywane sekwencyjne, albo tracone.

W przypadku systemów bez kronikowania i cache, możlie sa przykre 
sytuacje kiedy write zadziała niesekwencyjnie zapisując kawałki pliku w 
róznych miejscach a winnych nie i nie ma nad tym kontroli.

> Są narzedzia do tego 
> FS nic o spojnosci pliku nie wie

Ależ wie.

Dam Ci taki przykłąd.

Proces A kasuje plik. Wymaga to zmiany kilkudziesięciu bloków na dysku.

Proces B otwiera ten sam plik. Filesystem zapewnia że albo go otworzy 
albo nie. Nie ma sytuacji że "otworzy w trakcie kasowania przez inny 
proces i częśc danych będzie popsuta".

To jest spójność. Nie ma stanów niepewnych lub wręcz popsutych.

>> Struktura ma być odporna na wielodostęp. Inaczej: dowolna operacja na 
>> pliku wykonana w procesie A ba być widoczna spójnie w procesie B. 
>> Gwarantuje to *prawie* każdy filesystem.
> Pokaż jakiś przykład bo pierwsze słysze że Filesystem oodpowiada za 
> spojność - jaką spójność masz na mysli bo moze znowu mowisz o czymś co 
> zupelnie inaczej się nazywa

Powyżej wyjaśnienie.

>>> sprawy jak ty myslisz tutaj są potrzebne dodatkowe operacje o ktorych 
>>> ty nie zdajesz sobie sprawy
>> :D
> No wlasnie tylko tyle można zrobić z twoją próbą zbudowania czegokolwiek 
> - uśmiechnąć się

Przepraszam, ale pękam ze śmiechu od przedwczoraj. Nie wiem czemu. Może 
to z powodu pogody.

>> Nic. Do kosza. Kronikwanie nie słuzy do ratowania dupy w przypadku 
>> padu fizycznego dyku/partycji. Pomyliłeś z RAID.
> Wpisz "kroniki" w google a dowiesz się po co powstały bo tego nie wiesz.

U mnie chyba inny internet jest:

"A journaling file system is a file system that keeps track of changes 
not yet committed to the file system's main part by recording the 
intentions of such changes in a data structure known as a "journal", 
which is usually a circular log. In the event of a system crash or power 
failure"

> Zablysnąłeś wiedzą a ja na to powiem że mało wiesz

Wiem, że wiesz, że wiem.

> Ty pomijasz więcej niż ci sie wydaje ale cóż nie ja mam problem ale ty. 
> Ja akurat pracuje na czymś podobnym co chcesz osiągnąć - zbudowałem to 
> od zera wzorująć się na FAT32 i ntfs-3g i wlasnie VDI no ale co ja tam 
> wiem według ciebie to jest za mało.

Napisałeś ręcznie coś podobnego do ntfs-3g? Wow. To sorry. Możesz mieć 
rację we wszystkim, jesteś moim idolem. I to wszystko w OpenPascalu?

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

#34465

W dniu 2021.04.07 o 15:21, heby pisze:
> On 07/04/2021 14:58, J-23 wrote:
>> Ty pomijasz więcej niż ci sie wydaje ale cóż nie ja mam problem ale 
>> ty. Ja akurat pracuje na czymś podobnym co chcesz osiągnąć - 
>> zbudowałem to od zera wzorująć się na FAT32 i ntfs-3g i wlasnie VDI no 
>> ale co ja tam wiem według ciebie to jest za mało.
> 
> Napisałeś ręcznie coś podobnego do ntfs-3g? Wow. To sorry. Możesz mieć 
> rację we wszystkim, jesteś moim idolem. I to wszystko w OpenPascalu?
> 

Nie podobnego do ntfs-3g (i pozostałych elementow ktore wymienilem) ale 
wykorzystując wiedze na podstawie analizy zródeł a to różnica

A podobne rozwiązanie do Twojego tylko ja nie oznaczam że coś jest 
plikiem czy katalogiem

wspomniałeś w drugiej odnodze tego wątku cytując "Może podpowiem: 
powiększ środkowy plik o bajt."

Ja go właśnie tak powiekszam nawet o kilka dziesiąt mega i moge również 
zmiejszać ale ty nadal tego nie czaisz - znam doklładnie co chce tam 
wstawić a nie tak jak u ciebie odp że to "plik" mowiąc plik to akurat 
nic nie mowi. Twierdzisz że podałeś kilkadziesiąt razy w swoich postach 
co to ma być - nie podałeś ani razu. Tak samo nie wspomniałeś o api na 
które się powołujesz że jest niby w glownym w poście.

A gdzie ja napisałem że w Object Pascalu to po pierwsze. Masz jakieś 
urojenia - lub co najmniej problem z czytaniem ale to już zauważyłem dawno

Podsumowując życzę powodzenia bo nie da się rozmawiać konkretnie nie 
udzielając odpowiedzi na pytania. Nie tylko ja to zauważyłem tutaj ale 
mniejsza o to

Pozdrawiam
J-23

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web