Názory k článku
Red Hat pracuje na souborovém systému Composefs

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áře

Instalovat 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?

Proč 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.

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í.

Ochrana pred používateľom / útočníkom.

Presne toto robia mobilné telefóny, aby zabezpečili, že celý OS je v takom stave, ako vyšiel z továrne, resp. po podpísanom update a nie, že tam používateľ alebo útočník urobil nejakú úpravu.

sha1sum byl moc komplikovany, tak si inzenyri napsali svuj souborovy system? Nebo BTRFS neodhali pripadnou chybu s integritou souboru, tak si inzenyri napsali svuj souborovy system?

Je treba se nejak v te firme realizovat:-) Drive si kazdy matfyzak vymyslel programovaci jazyk, dnes je to FS.
Smysl mi unika. Zvlast kdyz ZFS umoznuje checksumy vypnout nebo si user muze prepnout algoritmus k vypoctu dle potreby.

Jo, jenže ZFS nemůžeš na úrovni distribuce bez obav použít, protože Oracle.

Já to chápu tak, že je snaha ty problémy s integritou řešit přímo na úrovni přístupu k FS, což nějaký sha1sum nesplňuje. A pokud bych chtěl mít (téměř) 100% jistotu, že to opravdu bude fungovat, btrfs by byl asi poslední z běžných FS, který bych použil.

Četl jste aspoň README k Composefs?

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í.

Me by zajimalo jak funguje filesystem ktery je jen pro cteni :)

Nic na nej nejde ulozit, tak logicky neni co precist, natoz overit.

Vidíte, a přitom takových souborových systémů existuje relativně dost.

Zrovna Composefs je udělaný tak, že máte na jiném souborovém systém jeden soubor s metadaty (názvy souborů apod.), přičemž v metadatech jsou i cesty k souborům, kde jsou uložená data. A nad tímhle je pak Composefs, který ten soubor s metadaty + odkazované soubory s daty zpřístupní jako nový souborový systém. Takže jsou to v podstatě takové vylepšené hardlinky (ke stejným datům se dostanete pod různými názvy, to umí i hardlinky, ale mohou k nim být i různá oprávnění, různé časy vytvoření souboru – to už s hardlinky neuděláte). Plus samozřejmě je podstatné to, že se to tváří jako nový FS, nejde do toho zapisovat (takže někdo omylem nepřepíše data sdílená s ostatními).

a pritom ho pouzivas pri instalaci systemu kdy instalacka ma bezne rootfs ulozen(+zkompri­movan) v readonly squashfs filesystemu ;-) to ze nastartovanej live mas pocit ze se uklada, je ze nad primontovanym ro squashfs je vrstva overlay (drive aufs, jeste drive unionfs) co uklada zmeny na nejaky rw filesystem (ram ci disk)