Re: Przenośny, uproszczony filesystem - Grupy dyskusyjne w eGospodarka.pl

eGospodarka.pl › Grupy › pl.comp.programming › Przenośny, uproszczony filesystem › Re: Przenośny, uproszczony filesystem

X-Received: by 2002:a05:620a:ec9:: with SMTP id x9mr12809424qkm.333.1612708461994;
Sun, 07 Feb 2021 06:34:21 -0800 (PST)
X-Received: by 2002:a05:620a:ec9:: with SMTP id x9mr12809424qkm.333.1612708461994;
Sun, 07 Feb 2021 06:34:21 -0800 (PST)
Path: news-archive.icm.edu.pl!news.icm.edu.pl!newsfeed.pionier.net.pl!2.eu.feeder.erj
e.net!feeder.erje.net!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2
.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnew
s.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: pl.comp.programming
Date: Sun, 7 Feb 2021 06:34:21 -0800 (PST)
In-Reply-To: <rvokfn$1ff$1@dont-email.me>
Complaints-To: g...@g...com
Injection-Info: google-groups.googlegroups.com; posting-host=77.254.35.244;
posting-account=xjvq9QoAAAATMPC2X3btlHd_LkaJo_rj
NNTP-Posting-Host: 77.254.35.244
References: <rtpdik$cge$1@dont-email.me>
<c...@g...com>
<rvokfn$1ff$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <9...@g...com>
Subject: Re: Przenośny, uproszczony filesystem
From: "M.M." <m...@g...com>
Injection-Date: Sun, 07 Feb 2021 14:34:22 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Xref: news-archive.icm.edu.pl pl.comp.programming:215349
[ ukryj nagłówki ]
On Sunday, February 7, 2021 at 12:55:37 PM UTC+1, heby wrote:
> On 05/02/2021 19:42, M.M. wrote:
> > W jakim sensie to by miało być optymalne?
> Nie musi być optymalne. To tylko optymalizacja user/programista. Z
> jednej strony wszystko w jednym pliku pakowanym ZIPem, z drugiej strony
> milion plików w których user może coś pozmieniać i nieszczęscie gotowe.
> Taki "filesystem w pliku" pozwoli kosztem niewielkiego spadu wydajności
> uzyskać spójny zbiór danych w którym user grzebać nie będzie, nawet
> przypadkiem.
>
> To tak "baza danych" tylko że zamiast tabel w środku sa same bloby...
> obecnie mam właśnie taką emulację, na sqlite. Ale to jest zupełnie
> niepotrzebne, ponadto taki wirtualny filesystem, przy odrobinie wprawy,
> pozwalałby na częsciowe mapowanie plików w pamięć, czego bloby w sql nie
> potrafią.

Jakbym musiał zaimplementować ręcznie bliżej nie określone rozwiązanie, to
bym zrobił listę na dysku. Nie wydaje się to szczególnie trudne.

Takich kilka chaotycznych/zgrubnych i nie do końca przemyślanych wskazówek : By
trzeba
zdefiniować rozmiar węzła, nagłówek dla wolnego węzła, nagłówek dla pustego węzła i
nagłówek pliku. W nagłówku pustego byłby adres następnego pustego - czyli lista
wolnych
węzłów. W nagłówku pliku adres pierwszego pustego węzła, jeśli by wskazywał na koniec
pliku, to nowy węzeł można utworzyć na końcu pliku przez zwiększenie rozmiaru. Za
nagłówkiem
pierwszy węzeł pliku z informacją o systemie plików, czyli nazwa pliku i pierwszy
węzeł pliku i
może jakieś dane pomocnicze, jak np. długość pliku, suma kontrolna, może nawet dane
naprawcze - to już zależne od szczegółowych wymagań. Nagłówek węzła pliku by musiał
zawierać adres następnego węzła a może także adres następnego 10tego węzła, wtedy
seek dla długich plików zadziałałoby 10 razy szybciej. Zwalnianie węzła można zrobić
przez wpis do węzła danych z na nagłówka pliku o następnym wolnym węźle, a do
nagłówka
pliku przepisujemy informację o nowym pierwszym wolnym węźle.

Aby znaleźć plik, trzeba przeszukać listę systemu plików. Nazwy plików mogą być też w
danych pliku, a w liście systemu plików tylko funkcje skrótu nazw plików, to powinno
przyspieszyć wyszukiwanie.

Odczyt pliku to odczyt danych z pierwszego węzła i skok do drugiego węzła, potem
odczyt z drugiego i znowu skok do kolejnego.

Optymalizowanie tego, dostosowywanie tego do konkretnego rozwiązania, już takie
łatwe nie jest.

Pozdrawiam