🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: pl.comp.programming
Article #217350

Re: Przenośny, uproszczony filesystem

#217350
From: heby
Date: Mon, 08 Feb 2021 13:57
47 lines
3853 bytes
On 08/02/2021 14:24, M.M. wrote:
>> To dopuszczalna sytuacja. fs ma być na nia gotowy.
> Trudno sie rozmawia, nie wiem co dla Ciebie znaczy że FS
> ma być gotowy. Skąd FS ma wiedzieć, czy to nie jest zaplanowane
> działanie programisty?

Ma nie wiedzieć. Jedyne co od niego oczekuje to to że nie rozwali sobie 
wewnętrznych struktur kiedy dwa wątki będą starały się jednoczesnie 
powiekszyć długość pliku albo skasować go w tym samym momencie.

> Pracują np. dwa wątki. Jeden pisze do
> pliku, drugi kasuje plik. Jeśli jeden najpierw zapisze, a drugi
> skasuje - to pliku nie będzie. Jeśli najpierw skasuje, a
> potem dojdzie do próby zapisania, to też nie będzie pliku - fs
> zwróci po prostu błąd zapisu.

Super. Tego właśnie oczekuje. Ma się nie rozsypać. To że w danych jest 
sieczka, to problem aplikacji, nie fs.

> Można zrobić taki rozwiązanie, że jak jeden wątek chce plik do
> zapisu, to FS czeka aż wszystkie inne wątki zamkną plik.

O nie.

>> Nieprawda. Jeśli jeden watek zapisuje jakas częśc pliku, inny może
>> zapisuwać inną część tego samego pliku. DB często tak robią.
> Dlatego pisałem NA TYCH SAMYCH DANYCH, a INNE CZĘŚCI PLIKU to już
> nie są TE SAME DANE.

To żadna róznica. fs nie obchodzi co i gdzie zapisuje. Jeśli ktoś 
zapisuje te same dane pikoseundę później to nie jest problem fs.

> Nie wiem... Dla mnie to brzmi trochę jak mieszanie rozwiązania szczegółowego z
> ogólnym. W szczegółowych zastosowaniach to programista wie które operacje
> powinny być atomowe i uzyskuje taki efekt poprzez synchronizację wątków.

Nie rozmawiamy tutaj o kliencie tego fs. W nim ta wiedza istnieje.

W fs nie ma żadnej wiedzy o atomowości operacji na plikach. Jedyne co 
wymagam od niego to fakt że "open" zadziała atomowo, "close" zadziała 
atomowo, "rm" itd. Ma pozwolić na 2x write jednocześnie w to samo 
miejsce i się nie rozlecieć.

> A budowa wewnętrzna dzienników to jest po prostu spis operacji i
> kopia danych które w razie usterki będzie trzeba odtworzyć.

To zdecydownie nie wygląda tak prosto w kodzie ext4...
Technical Details
Message-ID: <rvrfvp$4j2$1@dont-email.me>
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!news.icm.edu.pl!fu-berlin.de!3.eu.feeder.erje.net!feeder.erje.net!weretis.net!feeder8.news.weretis.net!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
References: <rtpdik$cge$1@dont-email.me> <cff484ae-3bf8-4cec-bbb7-78e44cb70167n@googlegroups.com> <rvokfn$1ff$1@dont-email.me> <90a1ad63-9675-4233-b822-808a7c17cbc7n@googlegroups.com> <rvpa3d$uf5$1@dont-email.me> <3ed1a847-2f93-4108-8985-2afae9b3b897n@googlegroups.com> <rvpgno$hnr$1@dont-email.me> <e8d86917-8e4c-4624-b8ae-67b82f80591cn@googlegroups.com> <rvpkev$d2u$1@dont-email.me> <b01525e0-6d35-48d8-ad1c-c9938aca307bn@googlegroups.com> <rvqmb3$dlt$1@dont-email.me> <797def6b-9fcd-4536-ba25-eab0e23081b8n@googlegroups.com> <rvr6ar$sst$1@dont-email.me> <b9c5e357-d30a-4dbc-9438-f5d6161b7d5dn@googlegroups.com>

Show Full Headers
Complete Article Headers
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!news.icm.edu.pl!fu-berlin.de!3.eu.feeder.erje.net!feeder.erje.net!weretis.net!feeder8.news.weretis.net!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: heby <heby@poczta.onet.pl>
Newsgroups: pl.comp.programming
Subject: Re: Przenośny, uproszczony filesystem
Date: Mon, 8 Feb 2021 14:57:12 +0100
Organization: A noiseless patient Spider
Lines: 47
Message-ID: <rvrfvp$4j2$1@dont-email.me>
References: <rtpdik$cge$1@dont-email.me> <cff484ae-3bf8-4cec-bbb7-78e44cb70167n@googlegroups.com> <rvokfn$1ff$1@dont-email.me> <90a1ad63-9675-4233-b822-808a7c17cbc7n@googlegroups.com> <rvpa3d$uf5$1@dont-email.me> <3ed1a847-2f93-4108-8985-2afae9b3b897n@googlegroups.com> <rvpgno$hnr$1@dont-email.me> <e8d86917-8e4c-4624-b8ae-67b82f80591cn@googlegroups.com> <rvpkev$d2u$1@dont-email.me> <b01525e0-6d35-48d8-ad1c-c9938aca307bn@googlegroups.com> <rvqmb3$dlt$1@dont-email.me> <797def6b-9fcd-4536-ba25-eab0e23081b8n@googlegroups.com> <rvr6ar$sst$1@dont-email.me> <b9c5e357-d30a-4dbc-9438-f5d6161b7d5dn@googlegroups.com>
Mime-Version: 1.0
Injection-Date: Mon, 8 Feb 2021 13:57:13 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="6d65b5dea5ea830f874d79f0ddf106aa"; logging-data="4706"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19GZZq6/kD/Q7RC4JQDg9Bm"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1
Cancel-Lock: sha1:NtNuro+PLxa3BVWNYVYnF8gtzpc=
In-Reply-To: <b9c5e357-d30a-4dbc-9438-f5d6161b7d5dn@googlegroups.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit