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