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:a37:812:: with SMTP id 18mr1760022qki.401.1612734811706; Sun, 07
Feb 2021 13:53:31 -0800 (PST)
X-Received: by 2002:a37:812:: with SMTP id 18mr1760022qki.401.1612734811706; Sun, 07
Feb 2021 13:53:31 -0800 (PST)
Path: news-archive.icm.edu.pl!news.icm.edu.pl!newsfeed.pionier.net.pl!goblin2!goblin3
!goblin.stu.neva.ru!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews
.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.goog
legroups.com!not-for-mail
Newsgroups: pl.comp.programming
Date: Sun, 7 Feb 2021 13:53:31 -0800 (PST)
In-Reply-To: <rvpkev$d2u$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>
<9...@g...com>
<rvpa3d$uf5$1@dont-email.me>
<3...@g...com>
<rvpgno$hnr$1@dont-email.me>
<e...@g...com>
<rvpkev$d2u$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <b...@g...com>
Subject: Re: Przenośny, uproszczony filesystem
From: "M.M." <m...@g...com>
Injection-Date: Sun, 07 Feb 2021 21:53:31 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 72
Xref: news-archive.icm.edu.pl pl.comp.programming:215357
[ ukryj nagłówki ]
On Sunday, February 7, 2021 at 10:01:21 PM UTC+1, heby wrote:
> On 07/02/2021 21:19, M.M. wrote:
> > Nie pytałem ile chcesz mutexów. Nie wiem do czego tej wiedzy potrzebujesz. Jak
tej
> > wiedzy potrzebujesz do zaprojektowania procesora - to ja nie pomogę.
> Nie projektuje procesora.

To dlaczego nie odpowiesz na pytanie: do czego potrzebujesz wiedzę o takich
szczegółach synchronizacji wątków?

>
> > Mutex
> > koncepcyjnie to prosta sprawa
>
> Tu mutex powinien być na "fragment" filesystemu.

Tu czyli gdzie i dlaczego na fragment filesystemu? Co rozumiesz przez filesystem?

>Jestem prawie pewny, że
> w normalnym fs takie "mutexy" są powiązane z kroniką co czyni jest
> bardziej mechanizmem transakcyjnym niż prostym lockiem.

Transakcje nie są prostym lockiem, aczkolwiek z poziomu użytkownika to proste
wywołanie funkcji, np. w bazie danych komenda "begin" rozpoczyna transakcje.
Transakcje umożliwiają naprawę tego co 'zaczęło' być modyfikowane.

> > zliczanie ile wątków przeszło przez jakąś barierę. Ale jaką techniką trzeba
napylić
> > tranzystory
> No wiec nie napylam tanzystorów.

Dlaczego więc chcesz wiedzieć jak wewnętrznie działają mutexy?

> >> Tak naprawdę, tam jest kilka innych zagadnień, których gotowce
> >> prawodpodobnie nie rozwiązują: np. defragmentacja w tle i powiązany z
> >> nim trim prawdziwego pliku.
> > Jeśli dysponujemy dodatkowym miejsce to defragmentuje się łatwo: odczytuje
> > się kolejne pliki z jednego systemu i zapisuje do drugiego.

> To jest naiwny algorytm.
Naiwne algorytmy mają swoje zalety.

> Wszystkie fs majace defragmentacje - robią ją w
> miejscu. Moe to zaprojektowc metodą garbage collectora z javy: stop the
> world. Ale coś czuje że to znowu naiwny algorytm.

GC zlicza odnośniki do alokowanych obiektów, gdy jest zero, to może zwolnić.
Jaka jest optymalna struktura do takiego zliczania? Może jakieś drzewo
zbalansowane i kolejka priorytetowa, a może naiwna liniowa tablica ma tak
mały narzut że to właśnie ją się najbardziej opłaca stosować dla typowych
aplikacji - nie wiem.

Pozdrawiam