Vlákno názorů k článku
Red Hat pracuje na souborovém systému Composefs
od Mintaka - Zajímavý směr. Proč ale řeší ověřování integrity souborů,...
-
Zajímavý směr. Proč ale řeší ověřování integrity souborů, které jsou v RO? To snad stačí ověřit jen po uložení a pak volitelně, když by bylo podezření na nějaký problém.
Jaký způsob byste doporučili dnes v situaci, kdy byste potřebovali sdílet data aplikací v rámci lokální sítě.
* server Linux Gentoo
* 60 klientských PC s Linux Mint
* gigabitová síť
* klienti mají malá 80GB SSDčka, ale je potřeba na nich provozovat hodně aplikací, které se tam najednou nevejdou
* některé aplikace jsou ve flatpak, některé ve snap, některé klasicky z repozitářeInstalovat aplikace z jednoho klienta a pak ty ostatní nějak přesvědčit, že už to mají nainstalováno?
A jak na sdílení souborů v těch aplikacích, nad kterými by všichni klienti chtěli mít výhradní práva k zápisu?
-
Filip JirsákStříbrný podporovatelProč ale řeší ověřování integrity souborů, které jsou v RO?
Abyste měl jistotu, že čtete opravdu ta data, která byla zapsána. Že nedošlo k jejich poškození třeba na disku. -
To mají tak velkou nedůvěru v záznamová média? Nebo mi něco uniká?
Data na RO disku jsem bral jako ta "lepší" možnost a když to šlo tak někde na RW aspoň třeba "chattr +i".
Záloha těch dat jinde a kontrola, až když se někde objevil problém, např. přes předpočítané md5, zip "-T" nebo rsyncem --dry-run, bývala dostačující. -
U systemu kde proteka mnozstvi dat muze chyba vzniknout i mimo medium. Typicky cache nebo buffery radicu. Nekde neco spatne v celem hw retezci raidu pokud neni v sw. Pri dnesni velikosti cache a velke hustote neni vyjimecne kdy vam v tom castice z kosmu udelaji bordel. Dalsi veci je treba momentalni brownout na komponentech, elektromagneticke ruseni, prepeti, nebo chyba ve vyrobe ci kombinace
Tam je pak dalsi otazka zda-li se obevuje chyba casto nebo v mezich definovane chybovosti a jestli mam zabezpeceny checksumem i transport.
V zasade souhlasim ze resit crc na kazdy prd je zbytecne. Napriklad pokud mam media s analogovym sumem v nezkomprimovane podobe tak mne sem tam bit rot netoci. Ale selhani cache radice uz by nadelalo velkou paseku.
-
Filip JirsákStříbrný podporovatel
To mají tak velkou nedůvěru v záznamová média?
Všichni mají tak velkou nedůvěru k pevným diskům, RAM, přenosům po síti. Proto se používají RAID, proto souborové systémy počítají kontrolní součty dat, proto se používají ECC RAM, proto mají síťové přenosy všude kontrolní součty.kontrola, až když se někde objevil problém
Když se z toho spouští kontejnerizované aplikace, chcete o chybě vědět hned a ne až nad tím poběží desítky kontejnerů a vy se o chybě dozvíte náhodou. -
<i>chcete o chybě vědět hned a ne až nad tím poběží desítky kontejnerů</i>
Pokud by to cílili na něco tak "kosmicky" kritického, aby při každém načítání kontrolovali data na RO disku, v tom případě, tohle řešit až na úrovni FS je pozdě.
To bych viděl jako úkol pro specializovaný HW řadič, který to bude číst ze 3 disků najednou a porovnávat shodu na každém bloku načtených dat.Nicméně se můžeme uklidnit, podle readme to vypadá, že tahle kontrola není ten hlavní usecase.
PS: Byl bych rád za tipy ohledně sdílení dat nainstalovaných flatpakových aplikací.
-
problémy s poškozenými daty v RO mountpointu jsou reálné a dnes se musí řešit na každém větším řešení.
Situací, které vedou k poškozeným RO datům je celá řada, namátkou:
- chyba při zápisu, ověření při zápisu je občas složité, kvůli čtení z cache a nikoliv ze samotného disku
- disky jsou vyloženě nespolehlivé, z várky 100 disků se vždy najde jeden, který nefunguje správně a má třeba vyšší chybovost čtených dat
- řada FS pro vzdálené připojení disků není odolná proti ukončení spojení a jsou schopni ti vrátit do userspace useknutý souborPorovnávat data při každém čtení je drahé a snižuje to rychlost, proto bývá vhodnější data kontrolovat průběžně na pozadí a obnovovat do správné podoby.
-
Filip JirsákStříbrný podporovatel
Nemusíte jít z extrému do extrému. Když to chcete spolehlivější, než mít data na disku pro SOHO použití, neznamená to, že hned potřebujete specializovaný HW řadič, který to bude číst ze třech disků zároveň. Spousta použití bude někde mezi.
Nebo se to dá napsat ještě jinak. Od moderního souborového systému už se zkrátka očekává, že bude kontrolní součty dat umět. Není to žádná raketová věda, ve spoustě způsobů užití je to užitečná vlastnost, tak proč to v souborovém systému nemít?
-
Hlavně, pokud nerozumíte psanému textu, tak ještě jednou: Jedná se o RO, tedy read only FS - něco jako třeba squashfs. To BTRFS či ZFS nesplňuje. Možnost zápisu přidává příliš složitosti.
A proč? Chtějí to použíť pro kontejnery - Docker, Pody, Flaptak a tak dále - image těchto věcí se stahují z internetu a bylo by hezké mít možnost ověřit, že jsou soubory uvnitř nepoškozené. Tento počin se mi lbí.
