🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: pl.comp.programming
Article #217348

Re: Przenośny, uproszczony filesystem

#217348
From: heby
Date: Mon, 08 Feb 2021 11:12
52 lines
4164 bytes
On 08/02/2021 11:08, M.M. wrote:
>> Wyobraź sobie dwa wątki: jeden dopisuje coś do wirtualnego pliku, a
>> drugi kasuje go.
> To jeszcze nic nie oznacza, może programista tak chciał?

To dopuszczalna sytuacja. fs ma być na nia gotowy.

> Ale generalnie
> na tym właśnie polega problem: kilka wątków pracuje na tych samych
> danych, zakładają że dane mają określoną wartość. Gdy jeden wątek dane
> zmodyfikuje, to pozostałe już pracują na błędnym założeniu. Dlatego
> robi się to co napisałem: jeśli jeden wątek zapisuje dane, to może
> pracować tylko ten jeden wątek, ale do odczytu może być dowolnie wiele.

Nieprawda. Jeśli jeden watek zapisuje jakas częśc pliku, inny może 
zapisuwać inną część tego samego pliku. DB często tak robią.

Granulacja jest więc dokładniejsza niż 1 plik. Co oznacza w naiwnym 
podejściu bardzo dużo muteksów na każdy kawałek pliku lub skomplikowany 
mutex z emulacją submutexów.

Przypuszcam że w ogóle sytuacja że zapisujemy ten sam kawałek pliku 
równolegle z dwóch wątków jest jak najbardziej dopuszczalna. Co najwyżej 
będzie race condition na dane, ale sam plik będzie dalej poprawny z 
punktu widzenia fs.

>> bo to wiem. Interesuje mnie jak działa zapewnianie spójności danych w fs
>> które dla usera wygląda jak typowy zasób krytyczny pilnowany przez mutex.
> Ale kto powiedział że jest takie zapewnienie?

W fs jest. Wątek A kasuje plik, wątek B czyta ten sam plik, wątek C 
właśnie go otwiera. I nie ma race conditions na poziomie fs, tam dane są 
spójne i stan jest atomowy.

> Jeśli dwa wątki zaczną
> czytać i pisać dane, to zepsują spójność danych w pliku, chyba że OS
> nie pozwoli otworzyć pliku do zapisu gdy jest może to spowodować
> utratę spójnośći.

To tak nie działa. POnadto rozróznijmy: race condition w aplikacji to 
coś innego niż race condition w fs. W tym drugim przypadku masz taką 
sytuację setki razy na sekundę w swoim PC.

>> Potrzebuje literatury z teorii działania systemów plików. Wygdybać mogę
>> sobie cokolwiek, ale konkuruje z dziesięcioleciami eksperymentów ludzi
>> mądrzejszych ode mnie.
> Może jest coś wartościowego?
> https://www.google.com/search?channel=fs&client=ubuntu&q=systemy+plik%C3%B3w+literatura

Obawiam się czy aby nie jest tylko od strony użytkowej. Ogólnie 
obejrzałem spisy kilkunastu książek z tego tematu i jak na razie nie 
widzę nic o budowie wewnętrznej. Być może coś przeoczyłem.
Technical Details
Message-ID: <rvr6ar$sst$1@dont-email.me>
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!news.icm.edu.pl!newsfeed.pionier.net.pl!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>

Show Full Headers
Complete Article Headers
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!news.icm.edu.pl!newsfeed.pionier.net.pl!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 12:12:26 +0100
Organization: A noiseless patient Spider
Lines: 52
Message-ID: <rvr6ar$sst$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>
Mime-Version: 1.0
Injection-Date: Mon, 8 Feb 2021 11:12:27 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="6d65b5dea5ea830f874d79f0ddf106aa"; logging-data="29597"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19nsTnNYMWWdix+SuI8blnK"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1
Cancel-Lock: sha1:2wY051m8WOe5NGawk5EfQZZ7fJw=
In-Reply-To: <797def6b-9fcd-4536-ba25-eab0e23081b8n@googlegroups.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit