Dotaz: fs XFS

[Pepan35]

Po velice špatných zkušenostech s btrfs jsem při reinstalaci Endeavouros použil souborový systém xfs. S ohledem na ssd mám ve fstab: UUID= / xfs defaults,lazytime,noatime,attr2,inode64,logbsize=256k,noquota 0 1

Mám tam nějaký parametr nevhodný pro ssd disk?

Odpovědi

[X]

Parametr 'attr2' je od kernelu 5.10 deprecated, 'inode64' je od kernelu 3.7 default. Zadny nevhodny osobne nevidim.

[Pepan35]

Děkuji moc. Uvedené jsem odstranil.

[Andrej]

Po velice špatných zkušenostech s btrfs…

S btrfs — nebo s rozbitým hardwarem, který maří data, což XFS bez checksumů dat nemá jak zjistit?

Hlavně když to nehlásí žádné chyby! Co na tom, v jakém stavu jsou data.

[Pepan35]

Ne Andreji, je to stále z přetrvávajících problémů ze subvolume viz: https://www.abclinuxu.cz/poradna/unix/show/495014

[Max]

Jo, ten thread si pamatuji. Téměř žádná spolupráce autora dotazu. Ptal jsem se 2x na logy a nic. Když by byly dodány logy, tak by druhá otázka směřovala, jaký hw se používá. Bohužel, pokud autor neměl snahu problém řešit, tak prostě pláče na špatném hrobě.
Zdar Max

[Pepan35]

Logy jsem nemohl (neuměl) dodat protože system byl nepoužitelný. Stalo se mi to ještě několikrát a tak jsem změnil fs a vše je ok delší dobu

[Andrej]

…a vše je ok delší dobu

Vše je zdánlivě OK, protože když FS neumí zjistit poškození dat, ničí se data vesele dál, jenom v tichosti.

[Andrej]

Logy jsem nemohl (neuměl) dodat protože system byl nepoužitelný.

Jasně. A live flashdisk byl určitě taky nepoužitelný. A pak Červená Karkulka snědla vlka.

[Pepan35]

Andreji to již zavání btrfs fanatismem Do problemantiky fs ani zdaleka nevidím jak ty, ale btrfs není tak dokonalý jako tady neustále prezentuješ. Až nebude Bcachefs experimentální tak ho jistě budeš stejně silně propagovat protože má mnohé výhody oproti btrfs a je mnohem rychlejší. Zkus si to v CachyOS.

Dlouhou dobu jsem používal jako většina ext3/4 a nikdy jsem o žádná data nepřišel. U btrfs během roku nejméně 6x. Naštěstí mám zálohy. Co je divného na nasazení XFS roky prověřeného fs?? Prostě mě několikrát naprosto náhodně btrfs subvolume z nějakých důvodů zklamalo a žádným způsobem jsem se JÁ neuměl k souborům dostat. Btrfs podle zkušeností jiných v žádném případě není všelék na pojebaný hw..

Ps Live flashdisk byl použitelný, ale k logům fs se mi nikdy nepodařilo dostat dokud jsem neobnovil btrfs na ssd

[Max]

...Btrfs podle zkušeností jiných v žádném případě není všelék na pojebaný hw...

To nikdo nikdy ale netvrdil. Vždy se říkalo, že pomůže odhalit vadný hw. Tj. btrfs začne vykazovat chyby a poukáže na chybu hw. S redundancí je schopno tu chybu i opravit (pokud se nebavíme o chybě, která by měla vliv na obě kopie).

BTW, stále nechápu, jaký je problém napsat "dmesg" a podívat se na chyby, co to hlásí?
Zdar Max

[pavele]

Jakože když budu mít vadný sata kabel tak to btrfs odhalí a chyby opraví?

[Max]

Pokud budeš mít vadný kabel, který způsobí chybný zápis na jeden disk, tak v případě kopie je možné ten špatný zápis opravit (btrfs scrub ,btrfs check). Aby na tu chybu nepřišel, musely by neustále sedět data i při čtení a vše okolo, což je dost nepravděpodobné. Navíc vadný sata kabel se projevuje crc chybami apod., takže vadný sata kabel odhalíš i bez btrfs.
Zdar Max

[Andrej]

Pokud budeš mít jeden vadný SATA kabel a 5 ostatních SATA kabelů v tomtéž RAID5 / RAID6 / RAID1 / RAID1C3 / … diskovém poli bude v pořádku, Btrfs samozřejmě

• chyby odhalí a
• opraví je při čtení, tj. nikdy nevrátí poškozená data, a
• po výměně vadného SATA kabelu je taky nakonec „definitivně“ opraví.

Pokud redundance chybí a jediný SATA kabel byl vadný a poškodil na jediném data, opravit je není jak⁽⁰⁾.

Tohle↑↑↑ je ovšem tak extrémně zjevné, až ani nevím, proč to sem vůbec píšu.

_{(0) Leda z Btrfs redundance v rámci jednoho disku (DUP), kdyby byla nastavená, ale to je jenom náhodná loterie; obě repliky můžou být v tahu.}

[alkoholik]

Urcite jsi chtel napsat RAID5 / RAID6?
Dej si prasek a bez radeji spat.

[Andrej]

Neplácej ptákoviny, když tomu ani za mák nerozumíš.

Btrfs RAID6 mám od roku 2016, stále totéž pole, funguje to znamenitě.

O Btrfs RAID 5/6 se vykládají hloupé pověry kvůli několika vzácným, ryze hypotetickým (v praxi nepozorovaným, leč teoreticky možným) scénářům podobným write hole.

Nicméně Btrfs RAID 5/6 je nesrovnatelně bezpečnější než „hardwarový“ (paskvilo-proprietární) AID 5/6 (bez R) i než dmraid / mdadm paskvilo-AID.

Jinými slovy, když už chce někdo „zavrhnout“ Btrfs RAID 5/6, musí podle této „logiky“ nutně zavrhnout v podstatě každý jiný (R)AID 5/6. (Kromě ZFS RAIDZ[N]; ten je samozřejmě cajk a srovnatelný s Btrfs.)

[alkoholik]

Kdyz vyvojari pisou v posledni verzi dokumentace should not be used in production, budu verit spis jim nez nejakemu pseudonymnimu trollovi.

[PetebLazar]

Měl jsem za to, že SATA protokol využívá IEEE 802.3 CRC k detekci chyb přenosu, jaká je pravděpodobnost vzniku chyby dat s tím, že CRC bude stále vyhovovat?

[MarV]

Ano dle specifikace je to IEEE 802.3 CRC a součet se dělá přes user data, která mohou mít až 8192B, plus hlavička 8B. Pro tento případ je pravděpodobnost nedekované chyby Pue ≤ 2^-32.

[PetebLazar]

To je předpokládám pravděpodobnost nedetekování chyby (kvůli CRC colision) v případě, že nastane chyba (SATA CRC error). Jaké je pravděpodobnost vzniku takových chyb?

U nahodile vzniklých chyb (SATA CRC error) to patrně bude méně frekventované, u systematikých chyb (např. problémový kabel) naopak časté takže k eskalaci problému výše asi dojde.

[MarV]

Ano je to pravděpodobnost, že CRC hlásí OK na poškozených datech (tj. v případě vícebitové chyby). Pravděpodobnost, že chyba vznikne a zároveň nebude detekována, bude součin těchto dvou pravděpodobností (což je asi jasné), takže to bude vždy méně, než ≤ 2^-32. Pravděpodobnost, že chyba vznikne samozřejmě závisí na tom, jak moc to je rozbité ...

[PetebLazar]

Pokud řešení využívá například i T10 DIF, pravděpodobnost nezachycené chyby se tím prakticky asi sníží na kladnou nulu.

[Pepan35]

A co mi ukáže dmesg když je btrfs nečitelný i z live distra??? Prostě v tu chvíli fs na disku jakoby neexistoval!

[Max]

Pokud ti kompletně zmizí fs z disku, tak to asi nebude chyba fs, ale někde jinde (zapomenutý raid, pokudsy s ním, nebo co já vím).
Zdar Max

[Pepan35]

raid jsem nikdy nepoužíval ani nezkoušel. Pomohla vždy pouze nová instalace, nebo obnova pomocí Clonezilla. "asi nebude chyba fs" a proč absolutně bez problémů funguje ext4, nebo xfs??

[Max]

Já se opírám o logy a fakta. Nevěřím, že něco jen tak samo zmízí. Apropo, jen tak pro zajímavost, o jaký hw se jedná (deska/řadič a disky)?
Zdar Max

[Pepan35]

Asus Prime z270-p i7-7700 kaby WD BLACK SN850X NVMe 1TB Heatsink

[Max]

Osobní PC:

[1][Pha][root@max ~]# btrfs fi show /
Label: none  uuid: a9bf9a20-6ffb-4a2a-952a-ab937941b0a6
        Total devices 2 FS bytes used 419.35GiB
        devid    1 size 929.91GiB used 574.03GiB path /dev/mapper/system
        devid    2 size 929.91GiB used 454.03GiB path /dev/mapper/system2

[1][Pha][root@max ~]# btrfs fi show /mnt/datastore/
Label: none  uuid: 883b2033-37ae-46f5-81a5-8af02b07005f
        Total devices 3 FS bytes used 5.55TiB
        devid    1 size 7.28TiB used 3.72TiB path /dev/mapper/datastore-dev1
        devid    2 size 7.28TiB used 3.72TiB path /dev/mapper/datastore-dev2
        devid    3 size 7.28TiB used 3.72TiB path /dev/mapper/datastore-dev3

Firemní pc

[29][root@devaine ~]# btrfs fi show /
Label: none  uuid: 1ab0f1bd-dd9c-448f-83cb-800215a333f5
        Total devices 1 FS bytes used 219.47GiB
        devid    1 size 229.98GiB used 229.98GiB path /dev/mapper/system

[29][root@devaine ~]# btrfs fi show /mnt/vms/
Label: none  uuid: d80a4574-0b6e-4c31-a292-9e8b0ec4199b
        Total devices 1 FS bytes used 414.91GiB
        devid    1 size 476.92GiB used 419.02GiB path /dev/mapper/datastore-vms

[29][root@devaine ~]# btrfs fi show /mnt/datastore
Label: none  uuid: 6f74aa7b-ac35-4c70-aa70-7a8b3940c191
        Total devices 1 FS bytes used 928.19GiB
        devid    1 size 931.50GiB used 931.50GiB path /dev/mapper/datastore1

Domácí server:

root@stor:~# btrfs fi show /
Label: none  uuid: 46abdeae-2212-42d1-8164-1694131d75c2
        Total devices 1 FS bytes used 33.20GiB
        devid    1 size 111.79GiB used 35.14GiB path /dev/sdd1

root@stor:~# btrfs fi show /mnt/datastore/
Label: none  uuid: 88076d9e-26ab-4764-875d-f513625dfbbc
        Total devices 4 FS bytes used 5.90TiB
        devid    1 size 5.46TiB used 2.51TiB path /dev/mapper/crypt_dev-part1
        devid    2 size 5.46TiB used 2.51TiB path /dev/mapper/crypt_dev-part2
        devid    3 size 5.46TiB used 2.51TiB path /dev/mapper/crypt_dev-part3
        devid    4 size 7.28TiB used 4.33TiB path /dev/mapper/crypt_dev-part4

ArchLinux i Debian, hafec let, žádný problém. Měl jsem jednou silent data corruption na původním serveru, kde na to btrfs krásně upozornilo, viz: Můj aktuální-nový domácí server (neměl jsem náhradní kopii, pod tím byl mdadm RAID5, šílená kombinace problémových disků atd.).
A to je tak asi vše. Jinak tedy ještě na všech firemních Synology běží btrfs.
Zdar Max

[lertimir]

Souhlas, už asi 10 let btrfs všude. A když byl s btrfs problém, vždy to bylo na konci problém s hw.

[Max]

Já ještě dodám, že v minulosti, když jsem nepoužíval btrfs, tak se mu stalo, že mi třeba po 5 letech, nebo i delší době, přestalo fungovat přehrávání třeba nějakého AV na disku, nebo začal fragmentovat obraz. A nebo se nenačetla nějaká fotka celá. Prostě to jevilo známky poškození, ale kdysi jsem neměl snahu něco takového řešit (generovat si ke všemu porovnávací hash, nebo zkoumat konkrétní AV dílo do hloubky, čím je způsobena chyba). Bavíme se třeba 15 let zpět.
Dnes to také neřeším, protože mám btrfs, nebo někde ZFS a ti mi řeknou, kde je problém, nebo ho sami opraví (pokud existuje více kopií). Rozdíl tedy je, že nemívám žádná data poškozena a mohu se na to spolehnout.
Zdar Max

[Pepan35]

Díky za info. Já ještě dodám že mě napadlo že nějak blbne slot nvme na desce (vyzkoušel jsem i ten druhý se stejným výsledkem) Koupil jsem tedy: https://www.alza.cz/axagon-pcem2-s-d5447159.htm?evt=ac a nastalo docela veliké zrychlení. Byl jsem rád, ale bohužel opět btrfs kleknul zcela stejným způsobem. Nebylo nic jiného než použít buď ext4, nebo xfs se kterým žádný problém nemám.Taky mě štve že se mi nepodařilo odhalit příčinu, ale nemám na to bohužel znalosti to odhalit proč to nepřiznat. Ještě jsem neuvedl skutečnost že btrfs nikdy neklekl při provozu pc a vše bylo ok. Rozbitý btrfs byl vždy po zapnutí pc cca po týdnu nebo 14 dnech. Již jsem to nevydržel po zapnutí pc sledoval loterii a obnovovat fs.

[flibor]

Ahoj, pokud se problém objevuje na různých slotech a různých discích, jedná se spíš o nějaký "systémový" problém s hardware. První co mě napadá, a to bude asi i nejpravděpodobnější scénář, je přehřívání ssd disků. Zatímco ostatní komponenty mají stabilní pracovní rozsah teplot až téměř ke 100 ˚C, ssd ocházejí daleko dříve. U notebooku se to dá částečně řešit vyčištěním vnitřku (to většinou moc nepomůže), nebo o něco lépe chladící podložkou. U klasického PC samozřejmě dostatečně dimenzované chlazení a případně nějaký ten dodatečný chladič přímo na ssd, pokud je na něj tedy místo.

[Pepan35]

Chlazením to není. PC se nepřehřívá ssd mám s chladičem teplota okolo 38 stupnu. Navíc to dělá po zapnutí PC jindy ne. Nebudu se s tím dále zabývat. S ext4 nebo xfs se mi to nestalo ani jednou

[majales]

@Max Jen k tomu Synology.. Pokud vím tak tam běží btrfs nad mdraid, nebo se pletu?

[Max]

Ještě donedávna to tak bylo. Zrovna před týdnem jsem jedno instaloval, ale opravdu jsem nezkoumal, zda to tak stále je. Ale věřím, že to mají vyzkoušeno a odladěno a se Synology mám jen dobré zkušenosti. Nicméně další nas je na cestě, tak pokud nezapomenu, tak se podívám. Standardně jedeme na Synology šifrování + btrfs + snapshoty v hodinových, nebo dvouhodinových intervalech v rámci pracovní doby.
Zdar Max

[Pepan35]

Tak s XFS se do dnešního dne žádný problém nevyskytl. Svoje předsevzetí že BTRFS na můj počítač nikdy nesmí dodržím!

[Luky]

Len tak mimo ma napadlo raz som niekde cital ze na klasicke pc ZFS nepatri kedze potrebuje pre ZFS mat ECC ramky asi dakde na freebsd fore. A tie systemy su dost podobne. Ja osobne pouzivam na zalohy tocive disky ked treba pripojim zalohujem a je to. Raid neni zaloha to vieme a na tocivych diskoch mam ext2. Som divny asi ale ext2 bez journalu ma to dobru kompatibilitu medzi linuxom a bsd, inac vsade davam ext4 na beziaci system. Btrfs je dovod preco moc nepouzivam fedoru kde je default.

[Peter Golis]

A kde to teda písali? Rád by som si pozrel celé to vyjadrenie, aby som sa uistil či neprišlo ku klasickému nepochopeniu. ktoré vytvára polopravdu horšiu od lži.

Hint: ECC odhaľuje náhodné chyby v RAM, aby zabránilo poškdeniu akýchkoľvek údajov. Tie chyby môžu poškodiť hocičo. Napríklad súborový systém, redundantné úložisko, databázu alebo hoci aj dátový tok multimedií. A že takéto poškodenie prehliadne nejaký FS neznamená že ten FS je vhodnejší alebo bezpečnejší. Taký FS len zatajuje vlastné chyby pred ich vlastníkom alebo užívateľom.

[Luky]

Ak pouzivas klasicky fs ako ext, ntfs tak si na tom horsie nez zfs bex pouzitia ecc, zfs a predpokladam aj btrfs ma checksumy takze tvoje data su vo vecsokmbezpeci, som obycajny uzivatel takze neviem ako zhodnotit ako funguju servery ale ak mas pc teda server predpokladam ze to je nejak hw alebo sw osetrene ze ti to da vediet ze ramka s ecc je chybna. Ako som napisal vyssie nesom fanusik fs ktory predpokladam ma veciu he reziu mne ak davam napr na pc na vyskusanie freebsd tak davam ufs a u linuxu povazujem ext4 na dost stabilny a ziadne hoaxy a polopravdy treba sa opytat google je vela otazok ohladommaj hw narocnostimnapr zfs

[Peter Golis]

A kde to teda písali? Rád by som si pozrel celé to vyjadrenie, aby som sa uistil či neprišlo ku klasickému nepochopeniu. ktoré vytvára polopravdu horšiu od lži.

Inak to upozornenie poznám veľmi dôverne. Len ma zaujíma či si to upozornenie pochopil, alebo len strieľaš tvoj dojmy ktoré si pletieš s pojmami.

PS: Aj EXT FS má checksumy, ale nemá ich tak aby chránili dáta pred poškodením.

[MarV]

K tomuto tématu bych považoval za celkem relevantní vyjádření od Matt Ahrens v diskuzi zde:

There's nothing special about ZFS that requires/encourages the use of ECC RAM more so than any other filesystem. If you use UFS, EXT, NTFS, btrfs, etc without ECC RAM, you are just as much at risk as if you used ZFS without ECC RAM. Actually, ZFS can mitigate this risk to some degree if you enable the unsupported ZFS_DEBUG_MODIFY flag (zfs_flags=0x10). This will checksum the data while at rest in memory, and verify it before writing to disk, thus reducing the window of vulnerability from a memory error.

I would simply say: if you love your data, use ECC RAM. Additionally, use a filesystem that checksums your data, such as ZFS.

[Peter Golis]

Tu je nutno podotknúť jednu drobnosť: ECC RAM sa moc nevyskytuje v prenosných počítačoch (notebook/tablet/smarthone), a ani v desktopoch. Skôr sa jedná o takmer výhradnú doménu podnikových serverov.

Ale to zvýšené nebezpečenstvo používania ZFS bez ECC RAM je pri používaní deduplikácie. Ak sa poškodia už deduplikované dáta, tak sa poškodia všetky ich "kópie". No a deduplikácia sa zvykne používať keď je treba z nejakého dôvodu šetriť diskovou kapacitou, takže sa tam asi moc nepoužíva redundantný zápis pomocou nejakého variantu RAID. Takže to dôrazné upozornenie má svoj dôvod. No a ak je čitateľ nepozorný a spojí si to s tým že ho o takej chybe neinformoval systém, tak je oheň na streche.

No ale kto by mal cenné dáta uložené len v jednej kópii a nekontroloval ich aspoň raz za čas, že áno. Hlavne pri cenách za úložný priestor.

PS: Môžeme vynechať argument typu: Mám cez dvadsať takmer identických strojov (VM/kontajnery), takže tam si môžem zapnúť deduplikáciu aj s redundantným zápisom a furt ma to bude stáť menej miesta. Také niečo už patrí na značkový server s ECC RAM. A je jedno na čom to bude postavené. Či to bude na BTRFS, ZFS, IBRIX, NETAPP, VDO, ReFS alebo na hocičom inom. Degradácia dát je reálna.

[Jendа]

There's nothing special about ZFS that requires/encourages the use of ECC RAM more so than any other filesystem.

Já si myslím, že taková speciální věc je neexistence fsck na ZFS (a obdobně pro btrfs, kde fsck sice existuje, ale je ve stavu "do not use"). Když se ti vlivem chyby RAM poškodí struktura, co budeš dělat? Jedině vytvořit nový a přelejt data?

[Andrej]

Já si myslím, že taková speciální věc je neexistence fsck na ZFS (a obdobně pro btrfs, kde fsck sice existuje, ale je ve stavu "do not use")

Tuhle přihlouplou a stokrát vyvrácenou pověru o fsck hodláš opakovat ještě dlouho?

Hele, to je ale zajímavé, že někomu tohle docvakne už koncem nultých let, na základě dokumentace k ZFS a (ranému) Btrfs, zatímco někomu jinému to ještě o 15 let později … ehm … působí nejasnosti. Inu, každý svým tempem, že jo…

Na kterém FS existuje fsck? Na základě představy o fsck, kterou výše naznačuješ (že zázrakem, záhadně, z křišťálové koule obnoví (meta)data ztracená kvůli selhávající RAM), nelze než konstatovat, že žádný FS nemá fsck; fsck dle tvých představ v tomhle vesmíru neexistuje.

Otázka je tedy stále stejná (už asi 10 let): S čím srovnáváš? Co je ten etalon, ten hypotetický ideální FS? Jmenuj ho, prosím. Jsem zvědavý. Už ho tajíš příliš dlouho. Nenechávej si to tajemství pro sebe.

Když se ti vlivem chyby RAM poškodí struktura, co budeš dělat?

Co si vojín Kefalín představuje pod takovým pojmem struktura? Asi metadata?

To↑ je ovšem nahrávka na smeč pro Btrfs, který (na rozdíl od špatných, zastaralých FS) implicitně (pokud uživatel nestanoví jinak) ukládá dvě kopie metadat (i na jednom zařízení), samozřejmě chráněné checksumy, aby se nepoškozená kopie (existuje-li ještě) dala s rozumnou pravděpodobností identifikovat. (Co když se obě kopie zapsaly ze stejné, poškozené RAM? Tak smůla, ale opět: S čím srovnáváme? Co by dopadlo lépe?)

Co tedy bude uživatel dělat?

• Pokud má béčkový zastaralý FS, například Ext4 nebo XFS, bude plakat, protože zastaralý FS nemá žádnou redundanci, aby mohl cokoliv obnovit, a fsck, jak už jsem psal, nemá křišťálovou kouli, aby si nenávratně ztracená (meta)data domyslel.
  Ba co hůř: v případě dat neumí vůbec poznat, že jsou poškozená!
• Pokud má rozumný souborový systém na jednom zařízení, první možnost záchrany jsou (implicitně) duplikovaná metadata chráněná obvyklými checksumy (v rámci téhož zařízení). Dokud rozsah poškození nezasáhne obě / všechny repliky důležitých metadat, s rozumnou pravděpodobností bude souborový systém čitelný a metadata opravitelná. Poškozená data, existují-li, budou identifikovatelná, ač (pochopitelně) neopravitelná. (Leda že by uživatel zvolil také duplicitní ukládání dat — který starý béčkový FS takovou volbu má, mimochodem?)
• Pokud má rozumný souborový systém na několika zařízeních, přibývá mnoho dalších možností opravy poškozených (meta)dat díky redundanci (kromě RAID 0). Checksumy řeknou, která replika nebo které RAID 5/6 bloky jsou (pravděpodobně) nepoškozené. Zbytek dat se doplní a dopočítá.
• Pokud je poškození takové, že jde všechno do kytek, půjde to na zastaralém FS do kytek s mnohem větší pravděpodobností. V takovém případě nezbude než sáhnout po oddělených zálohách (jiný systém, jiná instance FS). A právě atomické inkrementální zálohy nad řadou snapshotů jsou zase jedna z disciplín, ve kterých Btrfs září, zatímco zastaralé FS neumí nic.

Musím zopakovat (cca podvacáté) znova důvod, proč ZFS a Btrfs nemají zbytečný nesmysl zvaný fsck: Rozumný FS s checksumy, copy-on-write a redundancí musí být (v mezích zvolené redundance) funkční a odolný proti chybám, i když jsou chyby odhalené (nebo přímo nastanou) během provozu.

Izolovaný fsck, který funguje pouze na odmountovaném FS, nemá prakticky žádnou hodnotu, protože všechny podstatné mechanismy pro redundanci a obnovu / opravu dat musí být tak či onak součástí základního driveru příslušného FS. Neexistuje proto rozumný důvod tuhle logiku duplikovat, dvakrát odděleně testovat, (marně) doufat v udržení kompatibility mezi fsck s driverem, atd.

[Jendа]

Na kterém FS existuje fsck? Na základě představy o fsck, kterou výše naznačuješ (že zázrakem, záhadně, z křišťálové koule obnoví (meta)data ztracená kvůli selhávající RAM), nelze než konstatovat, že žádný FS nemá fsck; fsck dle tvých představ v tomhle vesmíru neexistuje.

Reálná zkušenost říká, že fsck na ext4 pravidelně někde najde chybu, opraví ji a jede se dál.

Rozumný FS s checksumy, copy-on-write a redundancí musí být (v mezích zvolené redundance) funkční a odolný proti chybám, i když jsou chyby odhalené (nebo přímo nastanou) během provozu.

To je pravda, kdyby to takhle fungovalo, tak by to bylo opravdu dobré. Nevím jak na ZFS (nikdy jsem nepoužíval), ale na btrfs tohle bohužel není moje zkušenost. Tedy v letech 2016-2020 nebyla, pak jsem se na to vykašlal. Pevně věřím, že dnes už je to lepší.

[MarV]

No takže ručně pustím fsck a on "najde" a "opraví" chyby, což prakticky znamená že: Poškozená data to nepozná a neopraví. Poškozená metadata to pozná a oprava pravděpodobně znamená, že něco se úplně vymaže, nějaké trosky se uloží do lost&found a když se dva soubory odkazují na stejný blok, tak uděláme kopii a je to opraveno ...

Co po takovém fsck uděláte dál? Budete doufat, že byla poškozena opravdu jen metadata a kromě reportovaných ztrát už nic jiného nechybí a loterie s "opravou" dopadla dobře?

Pokud na těch datech nezáleží, tak OK a není se o čem bavit. V opačném případě se to stejně musí obnovit ze zálohy.

[Andrej]

Reálná zkušenost říká, že fsck na ext4 pravidelně někde najde chybu, opraví ji a jede se dál.

To bych nenazval zkušenost, nýbrž domněnka a/nebo špatná interpretace příslušné situace:

• Jede se dál: Jsou všechna data v pořádku, bit po bitu? (Jak se to dá ověřit?)
• Ta údajná oprava je správná? Je ztrátová nebo ne? Proč se nedá provést online nebo při mountu?

Rozumnější interpretace bude, že Ext4 je zastaralý filesystém a že fsck nad Ext4 není zcela kompatibilní s driverem pro Ext4, což je pravděpodobné a u odděleného fsck v podstatě nevyhnutelné.

Rozumný FS s checksumy, copy-on-write a redundancí musí být (v mezích zvolené redundance) funkční a odolný proti chybám, i když jsou chyby odhalené (nebo přímo nastanou) během provozu.

To je pravda, kdyby to takhle fungovalo, tak by to bylo opravdu dobré. Nevím jak na ZFS (nikdy jsem nepoužíval), ale na btrfs tohle bohužel není moje zkušenost. Tedy v letech 2016-2020 nebyla, pak jsem se na to vykašlal. Pevně věřím, že dnes už je to lepší.

Nebyl to náhodou pokaždé příběh typu jeden starý disk na jednom starém křápu, který se dřív s ne-checksumovaným FS (mylně) zdál být funkční…? Rád bych podtrhl (tedy, aspoň ztučnil): …v mezích zvolené redundance…

Tady by mě opravdu zajímalo, kolika disků se ta špatná zkušenost týkala a jestli opravdu Btrfs ztratil data třeba v situaci s (dejme tomu) RAID1+ daty a RAID1C3+ metadaty… A ztratil je, nebo jenom zjistil, že už byla ztracená?

(Schválně jsem zmínil pouze RAID1+, ať nežeru; věřme na okamžik pověrám, že RAID 5/6 u Btrfs není lepší než kterýkoliv jiný (R)AID 5/6, byť ve skutečnosti je. Moje RAID 6 pole z roku 2016 stále funguje, ač jsem mu „pod rukama“ vyměnil 2 (naráz) selhávající disky, za pár let jsem ho bez ztráty kytičky přestěhoval (online) z 6 disků na 8 SSD a pak jsem 2 z těch SSD vyměnil; jedno selhalo po roce a jedno o 3 roky později… Pak jsem celé pole (online, jak jinak) překonvertoval z RAID6 metadat na RAID1C3 metadata, protože … dobře, když už ta pověra existuje, tak to zkusme. Flexibilita par excellence.)

[Pepan35]

Díky za vysvětlení, ale stále mi chybí odpověď proč fs BTRFS tak velice často klekl a systém nešlo nastartovat a z live se k kdatum v subvolume nešlo nijak dostat??? Nyní s XFS žádný problém není a po kontrole fyzicky stejného disku a testování RAM je úplně všechno ok. Přece někde chyba musí být! Podle mě je v fs BTRFS když je hw stejný a v naprostém pořádku.

K tomu jsi nikdy nedodal žádné logy. Proto se rady těžko dočkáš, resp. ses žádné nedočkal.

I ten live systém, kterým se snažíš dostat k datům na disku, má nějaké logy. A z těch by ses býval něco dozvěděl. Jenže ty jsi viděl jenom, systém nefunguje, live systém mi ten disk/subvolume nezpřístupnil, hned ten disk musím smazat. Takže postě smůla. Bez popisu chyb, které jsou právě v tom logu, se z toho nedá vyčarovat nic.

[Pepan35]

Proč jsem logy dodat nemohl??? Opakuju že jsem se do fs s BTRFS nedostal ani z live cd. Vždy pomohla jenom nová instalace!

[Peter Golis]

Ono to chcelo aj niečo iné, ako kliknúť na ikonku disku. Matne si spomínam že návody na vytiahnutie tých logov si dostal, ale prehliadol keďže boli zložitejšie ako kliknúť na ikonku disku.

Ty zřejmě nechápeš text. Takže znovu.

I ten live systém dělá log. A když se neúspěšně pokusíš připojit btrfs disk nebo přistupuješ neúspěšně na nějaký ten subvolume, který tam předtím byl, tak o tom něco napíše do logu. A to sis měl přečíst. Kdyby sis to přečetl, tak jsi sem vůbec nemusel psát, protože bys buď přímo věděl, v čem je problém nebo jsi to mohl dohledat někde na internetu. Ale dobře, mohl jsi to také poslat aspoň sem a někdo by z toho třeba něco vykoukal a poradil ti, co dál. Ale ty jsi to prostě neudělal. Jenom... nefunguje... přemažu.

Zlikvidovat btrfs dá dost práce. A pokud se tam něco sere, tak je plný log různých hlášek.

[Pepan35]

Text chápu, ale jsem obyčejný bfu a opravdu jsem netušil že v logu live bude log o nefunkčním disku, nebo subvolume. Při pokusu o otevření se jenom objevila hláška "file system system corrupted". Ani nevím kde bych ten log v live jako BFU hledal. Uznávám moje chyba, ale nemohu si dovolit mít týden kleklý desktop! Navíc nechápu jak bych to opravil, aby se to neopakovalo. Tak jsem to jako BFU přeinstaloval s XFS fs a mám pokoj. Nic jsem od té doby neřešil a při testech XFS žádná chyba a jednodenní test ram taky ok. Myslím kdybych tam dal ext4 nebo jiný fs než BTRFS tak by se to nestalo. Nezlob se na mě, ale trnout tejden že jednoho dne PC nenaběhne a data budu tahat ze zálohy na to fakt nemám nervy. BTRFS mi za to nestojí, i když přiznávám že že mě štve že se asi nikdy nedozvím co bylo přesnou příčinou.

[MarV]

Chtělo by to vidět nějaký skutečný výpis, proč to chcípá. Co vypíše ruční mount a dmesg?

Ruční "mount" a napsat "dmesg"

Když rada není dostatečně detailní na vaše znalosti, tak je dobré to zmínit a ne jen vyignorovat. Všem to ušetří spoustu práce ...

i když přiznávám že že mě štve že se asi nikdy nedozvím co bylo přesnou příčinou.

Jestli se dobře pamatuji, psal jsi, že se to opakovalo. Ale souborový systém se jen tak sám od sebe obvykle nerozbíjí. Natož potom opakovaně. Vždycky to bude mít nějakou příčinu. A jak bylo i zde uvedeno, btrfs často upozorní na to, že v hardwaru je něco shnilého.

Takže se může stát, že se nakonec dozvíš, proč došlo k poškození btrfs, protože pokud to byl hardwarový problém, tak se zase může objevit. Akorát na to přijdeš později než s btrfs.

[PetebLazar]

Pokud je chyba v implementaci souborového systému může se tento rozbít(či hlásit chyby) právě sám od sebe a vůbec k tomu není třeba HW chyby. https://tavianator.com/2024/btrfs_bug.html

[Pepan35]

Ale mě nikdy BTRFS neklekl při chodu PC. Po normálním vypnutí PC prostě počítač příště nenaběhl s hlášením že fs byl byl na disku poškozen. Pokaždé se to stalo náhodně během týdne nebo dvou.

[Peter Golis]

To bude asi karma.

[PetebLazar]

To bylo směřováno na přechozího přispěvatele jako příklad nekorektního chování filesystému i bez výskytu HW chyby. Myslím, že podmínkou popsané chyby bylo šifrování disku, kdy neúspěšný zámek nad bufferem umožnil jednomu vláknu obsah dekódovat(přepisovat) přičemž druhé vlákno v domnění exluzivity zajištěné zámkem nad bufferem s čistě načtenými nedešifrovanými daty z disku vyvolalo hlášení o jejich nekonzistenci (tyto byly v mezidobí v bufferu změněny druhým vláknem). Vzhledem k časově závislosti podmínek pro neúspěšnost zámku se tato chyba projevovala pouze v cca 5% případů konkurenčního využití bufferu.

Ale i v uvedeném případě v logu něco bylo...

[PetebLazar]

To je klidně možné, šlo mi pouze o limitovanou platnost věty: "Ale souborový systém se jen tak sám od sebe obvykle nerozbíjí.".

Chápu. Ale to pokrývá to "obvykle". Obvykle se nerozbíjí, někdy se ale stane, že se rozbije.

Mně zase šlo o ty logy.

[PetebLazar]

Ve výše popsané chybě k rozbití (nekozistenci) FS snad nedošlo, bylo pouze ohlášeno poškození dat (nesouhlasný checksum), který byl ve skutečnosti OK (na storage).