Article View: pl.comp.programming
Article #217350Re: Przenośny, uproszczony filesystem
From: heby
Date: Mon, 08 Feb 2021 13:57
Date: Mon, 08 Feb 2021 13:57
47 lines
3853 bytes
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-mailReferences:
<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