Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > pl.comp.programming > #34367
| Newsgroups | pl.comp.programming |
|---|---|
| Date | 2021-02-08 02:08 -0800 |
| References | (6 earlier) <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> |
| Message-ID | <797def6b-9fcd-4536-ba25-eab0e23081b8n@googlegroups.com> (permalink) |
| Subject | Re: Przenośny, uproszczony filesystem |
| From | "M.M." <mmarszik@gmail.com> |
On Monday, February 8, 2021 at 7:39:33 AM UTC+1, heby wrote: > On 07/02/2021 22:53, M.M. wrote: > > To dlaczego nie odpowiesz na pytanie: do czego potrzebujesz wiedzę o takich > > szczegółach synchronizacji wątków? > Ponieważ mutex w pamięci, dostarczany przez OS niekoniecznie jest tym > samym co "mutex" na plik (lock) zapewniajacy spójnośc dnych podczas > wielodostępu i defragmentacji w tle. Wymaga ręcznej implementacji, być > moze opartej o mutexy OSowe, a może niekoniecznie, a może w ogóle są > rozwiązania bez mutexa. Dane na których program pracuje to są dane, nie ma istotnego znaczenia czy są one zapisane w pamięci RAM, na dysku talerzowym, na dysku SSD, na płycie CD, DVD, itd. Podobnie dane naprawcze to dane naprawcze, jeśli są poprawne, to można dzieki nimi coś naprawić bez względu gdzie są zapisane. Jedyna istotna różnica jest taka, że jak padnie system, to też dochodzi do utraty danych w pamięci RAM i nie ma w niej nic do naprawiania. Dlatego w przypadku danych na pamięciach trwałych stosuje się nie tylko mutexy, ale jeszcze przechowuje się dane naprawcze, które (z tego co wiem zawsze) są w dzienniku zawierającym informacje o modyfikacjach. Mutex sam w sobie nic nie zapewnia, spójność danych uzyskuje się dzięki prawidłowmu użyciu mutexów i danych naprawczych. > >>> koncepcyjnie to prosta sprawa > >> Tu mutex powinien być na "fragment" filesystemu. > > Tu czyli gdzie i dlaczego na fragment filesystemu? Co rozumiesz przez filesystem? > Na przykład na wirtualny plik w tym kontenerze. > > 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ł? 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. > Można to rozwiązać za pomocą inodes, jak w linuxie. Albo za pomocą > mutexów "w filesystemie". > > Oczywiście te "mutexy w filesystemie" to naiwny koncept. To mogą być > zwykłe mutexy w implementacji filesystemu, ale raczej nie będą. > > > Transakcje nie są prostym lockiem > > Bo transakcja to kiepskie słowo. W zasadzie nie ma dobrego odpowiednika > w DB zachowania filesystemu z kronikowaniem zapisywanego przez wiele wątków. Też nie spotkałem się. > >>> 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? > Nigdzie nie napisałem że chce wiedzieć jak działają *normalne* mutexy, > 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? 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. OS powinien zapewniać tylko spójność struktury przechowującej dane na dysku, a robi sie to tak samo jak zawsze: mutexy i/albo dane naprawcze. > >> 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ć. > Wiem, ale GC nie pojawił sie tutaj jako odpowiednik 1:1 tylko jao zły > przykład "stop the world". Ok. > > 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. > 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 Pozdrawiam
Back to pl.comp.programming | Previous | Next — Previous in thread | Next in thread | Find similar
Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-01-14 13:31 +0100
Re: Przenośny, uproszczony filesystem "M.M." <mmarszik@gmail.com> - 2021-02-05 10:42 -0800
Re: Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-02-07 12:55 +0100
Re: Przenośny, uproszczony filesystem "M.M." <mmarszik@gmail.com> - 2021-02-07 06:34 -0800
Re: Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-02-07 19:04 +0100
Re: Przenośny, uproszczony filesystem "M.M." <mmarszik@gmail.com> - 2021-02-07 10:35 -0800
Re: Przenośny, uproszczony filesystem "M.M." <mmarszik@gmail.com> - 2021-02-07 11:03 -0800
Re: Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-02-07 20:57 +0100
Re: Przenośny, uproszczony filesystem "M.M." <mmarszik@gmail.com> - 2021-02-07 12:19 -0800
Re: Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-02-07 22:01 +0100
Re: Przenośny, uproszczony filesystem "M.M." <mmarszik@gmail.com> - 2021-02-07 13:53 -0800
Re: Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-02-08 07:39 +0100
Re: Przenośny, uproszczony filesystem "M.M." <mmarszik@gmail.com> - 2021-02-08 02:08 -0800
Re: Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-02-08 12:12 +0100
Re: Przenośny, uproszczony filesystem "M.M." <mmarszik@gmail.com> - 2021-02-08 05:24 -0800
Re: Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-02-08 14:57 +0100
Re: Przenośny, uproszczony filesystem "M.M." <mmarszik@gmail.com> - 2021-02-08 09:35 -0800
Re: Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-02-08 18:41 +0100
Re: Przenośny, uproszczony filesystem "M.M." <mmarszik@gmail.com> - 2021-02-08 10:47 -0800
Re: Przenośny, uproszczony filesystem Piotr Chamera <piotr_chamera@poczta.onet.pl> - 2021-02-08 20:33 +0100
Re: Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-02-08 20:35 +0100
Re: Przenośny, uproszczony filesystem J-23 <Baczeklu@poczta.fm> - 2021-04-05 03:51 +0200
Re: Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-04-05 11:30 +0200
Re: Przenośny, uproszczony filesystem J-23 <Baczeklu@poczta.fm> - 2021-04-05 20:27 +0200
Re: Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-04-05 23:04 +0200
Re: Przenośny, uproszczony filesystem J-23 <Baczeklu@poczta.fm> - 2021-04-05 23:55 +0200
Re: Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-04-06 10:58 +0200
Re: Przenośny, uproszczony filesystem Mateusz Viste <mateusz@xyz.invalid> - 2021-04-06 11:22 +0200
Re: Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-04-06 12:03 +0200
Re: Przenośny, uproszczony filesystem J-23 <Baczeklu@poczta.fm> - 2021-04-06 16:54 +0200
Re: Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-04-06 18:01 +0200
Re: Przenośny, uproszczony filesystem J-23 <Baczeklu@poczta.fm> - 2021-04-06 19:41 +0200
Re: Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-04-06 20:08 +0200
Re: Przenośny, uproszczony filesystem J-23 <Baczeklu@poczta.fm> - 2021-04-06 21:32 +0200
Re: Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-04-07 08:43 +0200
Re: Przenośny, uproszczony filesystem J-23 <Baczeklu@poczta.fm> - 2021-04-07 12:25 +0200
Re: Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-04-07 13:40 +0200
Re: Przenośny, uproszczony filesystem J-23 <Baczeklu@poczta.fm> - 2021-04-07 14:58 +0200
Re: Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-04-07 15:21 +0200
Re: Przenośny, uproszczony filesystem J-23 <Baczeklu@poczta.fm> - 2021-04-07 16:35 +0200
Re: Przenośny, uproszczony filesystem J-23 <Baczeklu@poczta.fm> - 2021-04-06 00:31 +0200
Re: Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-04-06 11:06 +0200
Re: Przenośny, uproszczony filesystem J-23 <Baczeklu@poczta.fm> - 2021-04-06 17:08 +0200
Re: Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-04-06 18:12 +0200
Re: Przenośny, uproszczony filesystem J-23 <Baczeklu@poczta.fm> - 2021-04-06 19:57 +0200
Re: Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-04-06 20:17 +0200
Re: Przenośny, uproszczony filesystem J-23 <Baczeklu@poczta.fm> - 2021-04-06 21:01 +0200
Re: Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-04-07 08:48 +0200
Re: Przenośny, uproszczony filesystem J-23 <Baczeklu@poczta.fm> - 2021-04-07 11:52 +0200
Re: Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-04-07 12:03 +0200
Re: Przenośny, uproszczony filesystem J-23 <Baczeklu@poczta.fm> - 2021-04-07 12:42 +0200
Re: Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-04-07 13:43 +0200
Re: Przenośny, uproszczony filesystem J-23 <Baczeklu@poczta.fm> - 2021-04-07 14:29 +0200
Re: Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-04-07 15:06 +0200
Re: Przenośny, uproszczony filesystem Roman Tyczka <romantyczka@hate.you.spammer> - 2021-04-09 12:04 +0200
Re: Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-04-09 13:42 +0200
Re: Przenośny, uproszczony filesystem Roman Tyczka <romantyczka@hate.you.spammer> - 2021-04-09 22:55 +0200
Re: Przenośny, uproszczony filesystem heby <heby@poczta.onet.pl> - 2021-04-10 12:21 +0200
csiph-web