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

do góry

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

do góry

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

No ale zrobili czy nie?

> Tutaj projektaci w IB/FB nie przejmowali się tym na etapie tworzenia
> struktury i ty też nie powinieneś

Łomatko...

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

O tym że najpierw muszę przeallokować strukturę w środku. Pod rygorem
wielodostepu i utrzymania spójności.

> Trzymaj się tematu bo odpływasz. Naprawde masz problem z zakodowaniem
> tego co wypisałeś w punktach w formie klasy z metodą SaveToFile

To takie proste? Wystarczy nazwać klasą "SaveToFile" i nagle wózki
dopisują kilkadziesiąt tysięcy lini kodu samodzielnie? WOW! Dzięki!

> 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

No wiec tam nie leży. Mimo że dalej traktujesz mnie jak idiotę to musisz
wiedzieć że ta apliakcja nie jest niedzielnym programikiem do robienia
faktur z OpenPascalu. To deczko bardziej wymagający kawałek kodu i różne
pomiary, analizy, doświadczenia i pomysły się już przewinęły. Powiedzmy,
że nie przejmowałbym się wydajnością czytania bloków z pliku, nawet
jesli po drodze jest warstwa translacji wirtualnego systemu plików.

do góry

W dniu 2021.04.07 o 08:48, heby pisze:
> On 06/04/2021 21:01, J-23 wrote:
>
> No wiec tam nie leży. Mimo że dalej traktujesz mnie jak idiotę to musisz
> wiedzieć że ta apliakcja nie jest niedzielnym programikiem do robienia
> faktur z OpenPascalu. To deczko bardziej wymagający kawałek kodu i różne
> pomiary, analizy, doświadczenia i pomysły się już przewinęły. Powiedzmy,
> że nie przejmowałbym się wydajnością czytania bloków z pliku, nawet
> jesli po drodze jest warstwa translacji wirtualnego systemu plików.

Argument z dupy bo nie ma nic wspolnego z tematem ty nie pojmujesz ze
twoj system plików jest tak naprawdę zwykłym formatem ktory da sie czytać.

Pozdrawiam
J-23

do góry

On 07/04/2021 11:52, J-23 wrote:
> zwykłym formatem

No właśnie. Niepotrzebnie dyskutujemy, to tylko zwykły format, do
napisania w każdym sklepie z formatami.

do góry

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

do góry

W dniu 2021.04.07 o 12:03, heby pisze:
> On 07/04/2021 11:52, J-23 wrote:
>> zwykłym formatem
>
> No właśnie. Niepotrzebnie dyskutujemy, to tylko zwykły format, do
> napisania w każdym sklepie z formatami.

Ty nie rozumiesz podstaw o których juz pisałem

Dla uproszczenia skupie się na dwóch elementach

co decyduje o tym co jest
a) katalogiem
b) plikiem

Wybierz sobie dowolny system plików i sprawdź.

Może wtedy pojmiesz że ty to musisz napisać sam lub wziąć to obadać na
podstawie istniejących rozwiązań

Bo ty ciągle powtarzasz jedno że chcesz pracować na pliku, ktory będzie
zachowywał się jak partycja i to jest zrozumiałe.

Nie zrozumiałe jest tylko to czego tak naprawdę szukasz bo wszystko
czego potrzebujesz masz dostępne w postaci kodu a że tego jest dużo i
dużo analizowania to inna bajka.

Pozdrawiam
J-23

do góry

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.

do góry

On 07/04/2021 12:42, J-23 wrote:
> co decyduje o tym co jest
> a) katalogiem
> b) plikiem

Nic, bo nie potrzebuję katalogów.

> Może wtedy pojmiesz że ty to musisz napisać sam

To akurat pojmuję.

> Nie zrozumiałe jest tylko to czego tak naprawdę szukasz bo wszystko
> czego potrzebujesz masz dostępne w postaci kodu a że tego jest dużo i
> dużo analizowania to inna bajka.

Dokładnie. Przykładowo nie wiem po co ludzie projektują rakiety skoro w
około jest pełno protonów, neutronów i elektronów którze można tylko
właściwie poskładać i wychodzi rakieta. Weźmy na przykład takie
procedury. Dzięki nim można napisać AI do rakiety! Naprawdę, nie sposób
przecenić takich rad.

do góry

W dniu 2021.04.07 o 13:43, heby pisze:
> On 07/04/2021 12:42, J-23 wrote:
>> co decyduje o tym co jest
>> a) katalogiem
>> b) plikiem
>
> Nic, bo nie potrzebuję katalogów.
>

Ty to co nazywasz katalogiem jest zbiorem bajtów zrozum to wreszcie. Bo
jak widać tego nie pojmujesz

>> Może wtedy pojmiesz że ty to musisz napisać sam
>
> To akurat pojmuję.


Nie pojmujesz bo szukasz gotowego rozwiązania. Tym samym pomijasz info
ze masz rozwiązanie.

Twoim rozwiązaniem jest wziąć adoptować system plikow i go przenieść na
to by pracował na pliku a nie na fizycznym dysku

Tylko ty nie pojmujesz tego że to wiąże sie ze zbudowaniem odpowiedniej
struktury

A no gdzie szukać informacji jak to zbudować - skoro potrzebujesz
funkcjonalności pliku to zobacz jak on jest zbudowany np na FAT czy
innym systemie wyciągnij wnioski i pisz

Dlaczego piszę że to moim zdaniem system pliktów to jest dużo na wyrost
bo to co potrzebujesz da się zrobić w dużo mniej skomplikowany sposob
niz Filesystem

Zrob prosty test zapakuj dwa pliki w jeden tylko nie zipem :) i co nie
da się na nich pracować - da tylko musisz wiedzieć jakie to są pliki i
co chcesz z nich wyciągnąć a ty poki co nic nie wspominasz jakiego typu
sa pliki ktore będziesz pakował czy znasz format tych plikow?

Brak jest podstawowej informacji co ty chcesz robić

Zapakować pliki w jeden to wystarczą strumienie i taką informacje żeś
dostal ode mnie

Napisales pracować na plikach czyli co z nimi robić

1. Obcinać/sklejać modyfikować a jeśli modyfikować to jak?

2. Uruchamiać te pliki

moge jeszcze dużo rzeczy wypisać o których nawet słowkiem nie
wspomnialłeś a są istotne

Pytałem w którymś poście budujesz symulator dysku - cisza brak odp

Domyslam sie że nie ale wypisanie 4 czy 5 punktow ktore ująłeś w którymś
poscie i pracowanie na tym to mi do zrobienia czegoś takiego wystarczą
strumienie. Kwestia tylko co rozumiemy przez prace na plikach o ktorej
nie wspomniales ani slowem


>
>> Nie zrozumiałe jest tylko to czego tak naprawdę szukasz bo wszystko
>> czego potrzebujesz masz dostępne w postaci kodu a że tego jest dużo i
>> dużo analizowania to inna bajka.
>
> Dokładnie. Przykładowo nie wiem po co ludzie projektują rakiety skoro w
> około jest pełno protonów, neutronów i elektronów którze można tylko
> właściwie poskładać i wychodzi rakieta. Weźmy na przykład takie
> procedury. Dzięki nim można napisać AI do rakiety! Naprawdę, nie sposób
> przecenić takich rad.

Widzisz i sam nie wiesz co czytasz. Bo dla mnie to nie jest poskładanie
protonow i neutronow a zdobycie doświadczenia na bazie tego co ktos
stworzył. Ty probujesz dostać gotowy pomysł i adoptować go do swoich
potrzeb a tak to nie dziala.

Pozdrawiam

do góry