-
Path: news-archive.icm.edu.pl!news.icm.edu.pl!fu-berlin.de!3.eu.feeder.erje.net!feede
r.erje.net!feeder1.feed.usenet.farm!feed.usenet.farm!news.uzoreto.com!fdc2.netn
ews.com!news-out.netnews.com!newsin.alt.net!fdcspool2.netnews.com!news-out.netn
ews.com!news.alt.net!fdc3.netnews.com!peer04.ams1!peer.ams1.xlned.com!news.xlne
d.com!peer03.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!newsfee
d.neostrada.pl!unt-exc-02.news.neostrada.pl!unt-spo-a-02.news.neostrada.pl!news
.neostrada.pl.POSTED!not-for-mail
Subject: Re: Przenośny, uproszczony filesystem
Newsgroups: pl.comp.programming
References: <rtpdik$cge$1@dont-email.me> <606a6d41$0$522$65785112@news.neostrada.pl>
<s4elb8$cni$3@dont-email.me> <606b5698$0$542$65785112@news.neostrada.pl>
<s4fu13$s6b$1@dont-email.me> <606b876c$0$517$65785112@news.neostrada.pl>
<s4h7rd$n3v$1@dont-email.me> <606c7635$0$529$65785112@news.neostrada.pl>
<s4i0k5$p2p$1@dont-email.me> <606c9d47$0$522$65785112@news.neostrada.pl>
<s4i82d$l12$1@dont-email.me> <606cb760$0$512$65785112@news.neostrada.pl>
<s4jka0$6mq$1@dont-email.me>
From: J-23 <B...@p...fm>
Date: Wed, 7 Apr 2021 12:25:14 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.9.0
MIME-Version: 1.0
In-Reply-To: <s4jka0$6mq$1@dont-email.me>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: pl
Content-Transfer-Encoding: 8bit
Lines: 225
Message-ID: <606d8889$0$505$65785112@news.neostrada.pl>
Organization: Telekomunikacja Polska
NNTP-Posting-Host: 95.160.17.234
X-Trace: 1617791114 unt-rea-b-01.news.neostrada.pl 505 95.160.17.234:51893
X-Complaints-To: a...@n...neostrada.pl
X-Received-Bytes: 10317
Xref: news-archive.icm.edu.pl pl.comp.programming:215449
[ ukryj nagłówki ]W dniu 2021.04.07 o 08:43, heby pisze:
> On 06/04/2021 21:32, J-23 wrote:
>> Rozwiązuje i to dużo problem w tym że tobie nawet się nie chce
>> poszukać źrodeł by zobaczyć jak to jest tam zrobione
>
> Może dlatego, że wiem jak są zrobione.
Po tym co piszesz widać że nie wiesz jak tam to jest zrobione.
>
>> Bląd bo ja używam tego trywialnego kontenera do zbudowania "warstwy",
>> "formatu", "filesystem" do ktora pozwoli Ci zapisać co chcesz i
>> operować tym jak chcesz.
>
> Zbudowanie warstwy zapisującej bloki jest *trywialne* w porównaniu ze
> zbudowaniem tego "formatu", jak go nazywasz.
>
>> A biorąc Twoje wymagania pod uwage opisane w odrębnym poscie tego
>> wątku nie są one skomplikowane
>
> Tak Ci się tylko wydaje.
Tak sie składa że na codzień pracuje na plikach które mają fizycznie
ponad 100 GB i jakoś nie mam dylematow jak Ty
>
>>> W środku jest czarna dziura. W dodatku skomplikowana, którą nazywasz
>>> "formatem" - weź se napisz. No więc to nie jest trywialne.
>> No i co tych plików nie możesz wpakować do tej struktury którą utworzysz?
>
> Zabawny jesteś nie pojmując że to "wpakowanie do struktury" jest
> zagadnieniem nietrywialnym. Troche jak przeszkolak "Tatusiu, to nie
> możesz jutro zbudować tego domu? Przecież masz już rysunek."
Problem w tym że ty próbujesz od nas czytających dowiedzieć się o
rozwiązaniu ktore tylko ty znasz jego przeznaczenie. Sam niestety
grzebierz za głębko ale sobie z tego sprawy nie zdajesz
>
>>> To już rozwiązaniem nie jest plik z maszyny wirtualnej?
>> Nie w 100% ale w 80% procentach masz w tym pliku gotowe roziwązanie
>> wystarczy je zgłębić
>
> Zgłebić ten prosty translator bloków z trim? A co ja tam znajdę nadto,
> czego nie wiem?
>
To znajdziesz jak w 80% napisać taką strukture ale podobno znasz ten
format wiec jak to jest? Znasz czy nie?
>>> Obawiam się że nie mieszam. Mogę był głupi, ale akurat na tym się
>>> trochę znam. Wbrew pozorom napisałem kilka rzeczy w życiu, były tem
>>> też proste filesystemy.
>> Wiec co ci przeszkadza wykorzystać to doświadczenie lub nawet pokazać
>> to co zrobiles do tej pory (mam na mysli te male filesystem)
>
> Nic mi nie przeszkadza (gdybym był głupi). Ale ponieważ z wiekiem rośnie
> pojmowanie swojej niewiedzy, wolałbym podeprzeć się opiniami kogoś kto
> ma większe pojęcie.
>
> Niestety te "filesystemy" były też komercyjne. Ale to nic wielkiego, w
> zasadzie bez znaczenia.
To że byly komercyjne nie znaczy że wiedza ci po nich nie pozostała i
nie możesz na tej wiedzy bazować. To co napisałeś brzmi "wiem jak dziaja
filesystem ale nie moge tej wiedzy wykorzystać bo korzystalem z niej
komercyjnie w projekcie" Smiech na sali :)
>
>>> Napisałem to kilka razy. Napiszę ponownie: aby utrzymać spójnośc
>>> danych. Na ten przykład wiele programów pakuje swoje małe pliczki do
>>> jednego ZIPa czy tar.gz, zmienia mu nazwę i masz .foo.
>> Wiec z czym masz problem z upakowanienem tego, z wielodostępem?
>
> To co napisałem już kilka razy: aby na tym pracować. Na ZIP nie da się
> pracować, wymaga wypakowania i ponownego spakowania za każdy razem, to
> storage a nie filesystem.
>
>> Bo ja tak naprawdę widze jeden problem z wielodostępem bo wielodostęp
>> jest zależny od systemu plikow na jakim sie plik znajduje i to jedyny
>> problem jaki widze na teraz
>
> Akurat od tego ani troche nie zależy. Cały ten filesystem może byc w RAM
> albo na kartach perforowanych, niewiel to zmienia. To gdzie będą
> zapisywane bloki jest zupełnie poza dyskusją.
>
>>> To ja chce wiecej. Chce móc na tym pracować, a nie tylko używać jako
>>> storage.
>> Od kiedy nie można pracować na "pliku"? Możesz go wczytywać
>> fragmentami możesz go wczytać w calosci (o ile ci starczy pamięci) i
>> na nim pracować
>
> Spróbuj odczytać "fragment" pliku ZIP, popracować w pamięci i zapisać
> ponownie w środku, o innej długości (bosię inaczej spakował). Daj znać,
> jak poszło.
>
Nie rozumiesz że to co ty nazywasz plikiem to dla pamieci jest takim
samym blokiem pamieci jak wszystko inne
To czy coś jest plikiem lub katalogiem decyduje Filesystem
Gdzie podobno ty proste filesystemy pisales i tego nie wiesz - ciekawe.
>>> Polecam konsultację z mount -o loop pod Linuxem, może zauważysz, że
>>> *plik* mozna traktować jako nośnik filesystemu. Jego "format" staje
>>> się wtedy filesystemem wprost.
>> A to kolego zależy już faktycznie od Filesystem a nie od mount. Twoj
>> Filesystem już i tak będzie leżał na jakimś systemie plików - chyba że
>> będziesz go zapisywał bezpośrednio na dysku (z pominięciem systemu
>> plików) w co wątpie
>
> To gdzie będzie leżał jest kompletnie bez znaczenia. W przypadku unit
> testów będzie sobie leżał w char* foo;
>
>>> 1) wielodostępie (a tym samym blokowaniu). Z watków (łatwe) i
>>> procesów (łomatko!)
>> Za to odpowiadać będzie system plików na którym będziesz trzymał swój
>> FileSystem
>
> Widać że nie masz sladu pojmowania o czym mowa. Wyobraź sobie
> std::vector i dwa wątki. Czyje zadanie jest zrobić synchronizacje?
> Kontrolera pamięci, który nei ma pojęcia o atomowości operacji, czy
> programista?
>
Widać masz za małe doświadczenie na wątkach... trudno nie będe Ci tego
tlumaczył bo znowu nie zrozumiesz i stwierdzisz że nie o tym mowie co ty
uważasz
> Niby jak wielodostęp do rzeczywistego pliku ma mi pomóc w utrzymaniu
> spójności danych w *środku*, w wirtualnych plikach?
>
> Jesli dalej nie pojmujesz, to zrób doświadczenie:
>
> Wyobraż sobie plik który ma dwa bajty.
>
> I kilka procesów, które realizują taki algorytm: czytają pierwszy bajt,
> podnoszą o jeden i zapisują, po czym czytaja drugi bajt, podnoszą o
> jeden i zapisują.
>
> Starujesz od 0x0000
>
> Kto ma zagwaratnować że po chwili w tym pliku, kazdy odczyt sekencyjny,
> bedzie zwracał dwa bajty o tych samych wartościach?
Znowu kłania się brak wiedzy o wątkach
Zastanów się i odpowiedz na jakim to ma środowisku działać bo raz
piszesz że nie ma to większego znaczenia a drugi razem piszesz o
operacji na wątkach.
A wiedza na czym to ma działać zmienia diametralnie podejsście do tego
co chcesz
>
> Czaisz bazę, gdzie możesz sobie wsadzić wielodostep na poziomie OSu?
Wlasnie nie wiem czego bo nie określiłeś na czym to ma działać
>
>> Tutaj zależy jak zorganizujesz usuwanie elementów bo można to zrobić
>> tak jak to robi np FB i będzie puchło a można usuwać konkretne bajty i
>> nie będzie puchło wsszystko zależy od tego co chcesz osiągnąć
>
> Konkretne bajty można usuwać z pliku? Owszem, jest pojęcie "pliku z
> dziurami" na Unixach, ale to nie działa jak myslisz.
To działa jak myśle tylko tyle że sama operacja trim nie zalatwia ci
sprawy jak ty myslisz tutaj są potrzebne dodatkowe operacje o ktorych ty
nie zdajesz sobie sprawy
>
>>
>>> 3) garbage collecting aby nie puchło bez powodu
>>> 4) kronikowaniu
>> Chcesz trzymać kronikowanie w tym samym pliku? Marny pomysł nawet
>> partycje przechowują to oddzielnie
>
> Zabawne. Bo tak nie jest. Mój plik fizyczny to taka "partycja", tylko że
> zamiast bycia kawałkiem dysku, jest całym plikiem. I jeszcze raz:
> kronika trzymana jest w środku partycji. Przynajmniej w popularnych fs
> które znam.
>
Trzymana na partycji. Jesteś pewien? Otóż takie pytanie to po co te
kroniki są i co w wypadku uszkodzenia partycji? Pomyśl chwile
Bo teraz gadasz głupoty z rozpędu lub nie wiesz do czego te kroniki sluza
>> Pierwsze wersje będa napewno nie wydajne ale musisz zacząć coś pisać a
>> potem to optymalizować bo inaczej się zamotasz
>
> Bzdura.
A to Ciekawe od ręki wiesz ze to co piszesz jest super optymalne.
Gratuluje :)
>
>>> Nie przypuszczam aby FAT obsługiwał poprawnie trim i GC. I nie wiem
>>> czy można go używać bez licencji (ktoś wie czy MS jeszcze grozi
>>> paluszkiem?).
>> Trim jest to zwykle obciecie bajtów tyle to po pierwsze
>
> Dziękujemy Kapitanie Obvious.
>
>> GC nie znajdziesz w żadnym systemie plikow bo ono jest gdzie inidziej to
>
> Ojej!
>
>> Po trzecie podałem przykład Fat16 zebys sobie zobaczył jak jest
>> zbudowany a nie go używał
>
> No ale ja wiem jak jest zbudowany. Nijak to nie rozwiązuje tych
> problemów z twojego zakresu "itd" które tak usilnie starasz się ignorować.
Dziwne nagle Filesystem nie rozwiązuje tego co chcesz. A podobno to co
Tworzysz to Filesystem wiec jak to jest?
Pozdrawiam
J-23
Następne wpisy z tego wątku
- 07.04.21 12:42 J-23
- 07.04.21 13:40 heby
- 07.04.21 13:43 heby
- 07.04.21 14:29 J-23
- 07.04.21 14:58 J-23
- 07.04.21 15:06 heby
- 07.04.21 15:21 heby
- 07.04.21 16:35 J-23
- 09.04.21 12:04 Roman Tyczka
- 09.04.21 13:42 heby
- 09.04.21 22:55 Roman Tyczka
- 10.04.21 12:21 heby
Najnowsze wątki z tej grupy
- 7. Raport Totaliztyczny: Sprawa Qt Group wer. 424
- TCL - problem z escape ostatniego \ w nawiasach {}
- Nauka i Praca Programisty C++ w III Rzeczy (pospolitej)
- testy-wyd-sort - Podsumowanie
- Tworzenie Programów Nieuprzywilejowanych Opartych Na Wtyczkach
- Do czego nadaje się QDockWidget z bibl. Qt?
- Bibl. Qt jest sztucznie ograniczona - jest nieprzydatna do celów komercyjnych
- Co sciaga kretynow
- AEiC 2024 - Ada-Europe conference - Deadlines Approaching
- Jakie są dobre zasady programowania programów opartych na wtyczkach?
- sprawdzanie słów kluczowych dot. zła
- Re: W czym sie teraz pisze programy??
- Re: (PDF) Surgical Pathology of Non-neoplastic Gastrointestinal Diseases by Lizhi Zhang
- CfC 28th Ada-Europe Int. Conf. Reliable Software Technologies
- Młodzi programiści i tajna policja
Najnowsze wątki
- 2024-12-12 Warszawa => Administrator Bezpieczeństwa IT <=
- 2024-12-12 Ostrów Wielkopolski => Trener zespołu sprzedaży Call Center <=
- 2024-12-12 Kraków => Key Account Manager <=
- 2024-12-11 SEP 1 kV E
- 2024-12-11 DNS restrictions are on
- 2024-12-11 wielkie bu
- 2024-12-11 Białystok => Inżynier bezpieczeństwa aplikacji <=
- 2024-12-11 Aku LiPo źródło dostaw - ktoś poleci ?
- 2024-12-11 Warszawa => Specjalista Bezpieczeństwa Informacji <=
- 2024-12-11 Wrocław => Application Security Engineer <=
- 2024-12-11 Warszawa => Analyst in the Trade Development department (experience wi
- 2024-12-11 Lublin => Programista Delphi <=
- 2024-12-11 Motodziennik #305 Nowy ELEKTRYK za 350 złotych miesięcznie? Kreatywne kredytowanie problemów
- 2024-12-11 Warszawa => Spedytor Międzynarodowy <=
- 2024-12-11 Katowice => Key Account Manager (ERP) <=