Silent Data Corruption NEEXISTUJE!

4.3. 00:49 | Přečteno: 1357× | Unix, Linux, ArchLinux | poslední úprava: 4.3. 05:38

O čem tohle asi tak může být?

Děkuji za kliknutí na clickbait. Chci jen říci, že už se tuze těším, jak mi zase nějaký představitel pozdního šulinismu (ježto vrcholný šulinismus už je, doufejme, dávno v propadlišti dějin) bude někde v diskusi tvrdit, nejlépe anonymně, že silent data corruption vůbec neexistuje a že je tudíž v nejlepším pořádku používat zastaralé souborové systémy typu Ext4.

Inu, světe div se, zhovna jsem dostal od monitoru logů levidelný alert, který se týkal jednoho z pravidelných scrubů na různých strojích. Dívám se (dívám, a ty spíš), copak se posralo. A ejhle:

Mar 03 22:56:28 kernel: BTRFS: device label X5 devid 1 transid 4327 /dev/mapper/x5_plain (254:1) scanned by mount (26739)
Mar 03 22:56:28 kernel: BTRFS info (device dm-1): first mount of filesystem 90040c24-93e4-4dfc-b61c-497e26cf063a
Mar 03 22:56:28 kernel: BTRFS info (device dm-1): using xxhash64 (xxhash64-generic) checksum algorithm
Mar 03 22:56:28 kernel: BTRFS info (device dm-1): using free-space-tree
Mar 03 22:56:33 kernel: BTRFS info (device dm-1): scrub: started on devid 1
Mar 03 22:56:52 kernel: nvme1n1: Read(0x2) @ LBA 9881392, 128 blocks, Unrecovered Read Error (sct 0x2 / sc 0x81) MORE DNR 
Mar 03 22:56:52 kernel: critical medium error, dev nvme1n1, sector 79051136 op 0x0:(READ) flags 0x0 phys_seg 110 prio class 3
Mar 03 22:56:52 kernel: BTRFS error (device dm-1): fixed up error at logical 39375339520 on dev /dev/mapper/x5_plain physical 40457469952
Mar 03 22:56:52 kernel: BTRFS error (device dm-1): fixed up error at logical 39375339520 on dev /dev/mapper/x5_plain physical 40457469952
Mar 03 22:56:52 kernel: BTRFS error (device dm-1): fixed up error at logical 39375339520 on dev /dev/mapper/x5_plain physical 40457469952
Mar 03 22:56:52 kernel: BTRFS error (device dm-1): fixed up error at logical 39375536128 on dev /dev/mapper/x5_plain physical 40457666560
Mar 03 22:56:52 kernel: BTRFS error (device dm-1): fixed up error at logical 39375667200 on dev /dev/mapper/x5_plain physical 40457797632
Mar 03 22:56:52 kernel: BTRFS error (device dm-1): fixed up error at logical 39375339520 on dev /dev/mapper/x5_plain physical 40457469952
Mar 03 22:56:52 kernel: BTRFS error (device dm-1): fixed up error at logical 39375339520 on dev /dev/mapper/x5_plain physical 40457469952
Mar 03 22:56:52 kernel: BTRFS error (device dm-1): fixed up error at logical 39375667200 on dev /dev/mapper/x5_plain physical 40457797632
Mar 03 22:56:52 kernel: BTRFS error (device dm-1): fixed up error at logical 39375536128 on dev /dev/mapper/x5_plain physical 40457666560
Mar 03 22:56:52 kernel: BTRFS error (device dm-1): fixed up error at logical 39375339520 on dev /dev/mapper/x5_plain physical 40457469952
Mar 03 22:59:01 kernel: BTRFS info (device dm-1): scrub: finished on devid 1 with status: 0

Z výše uvedeného bych rád citoval zejména:

• fixed up error
• scrub: finished on devid 1 with status: 0

Tak co, vymyslel si tohle celé Btrfs? Třeba jo. Jenže šḿářťčťľ říká, že ne:

Error Information (NVMe Log 0x01, 16 of 64 entries)
Num   ErrCount  SQId   CmdId  Status  PELoc          LBA  NSID    VS  Message
  0        232     4  0xb248  0xc502  0x000      9881395     1     -  Unrecovered Read Error

<ostrava>To přece neňy obnovytelne, na jeďynem zařyzeňy!!!</ostrava> Nebo jo? Co když jo? DUP!!! A ano, že to zasáhlo zhovna jenom metadata, to je (kupodivu) štěstí.

# btrfs fi df /x5/backup
Data, single: total=313.00GiB, used=268.31GiB
System, DUP: total=64.00MiB, used=64.00KiB
Metadata, DUP: total=8.00GiB, used=5.61GiB
GlobalReserve, single: total=512.00MiB, used=0.00B

Tak. A teď ať mi nějaký fantasta zase vysvětlí, jak přesně by tohle ustál Ext4 se svým bájným fsck, který prý dokáže opravit neopravitelné a vymyslet si data, která už neexistují.

• Řekl by Ext4 vůbec něco? Jestli jo, tak kdy přesně? Za uherský rok, až příslušný kousek metadat bude náhodou potřeba? Nebude pozdě? Nemělo už být zařízení nahrazené hovnovým?
• Řídil by se Ext4 náhovnými metadaty? Dobrá, neřídil; aspoň metadata má totiž checksumovaná. Lepší otázka tedy bude:
• Obhovnovil by Ext4 ta poškozená metadata? Ne. To opravdu ne. Leda tak ve snu.
• A co kdyby se tohle stalo v datech? Řekl by Ext4 na férovku, že ta data už prostě nemá, nebo by nenápadně vracel náhovné smetí? Smetí! Vracel by smetí.

Tak fajn. To bychom měli. Popírači silent data corruption všech zemí, jděte už konečně do prdele.

       

Komentáře

[karkar]

Fakt si do dostal zhovna?

[karkar]

tvl to je den, podělám i trolící narážku na hovna

[Gréta]

sem se teda jako šprajcla hnedka u googlení slovička 'levidelný' :D

myslimže takový slovo NEEXISTUJE :O :D :O :D

[Jendа]

Zajímavé je, že všechny reporty "silent data corruption", které jsem viděl, se neobsahují ani náznak pokusu o analýzu příčiny či typu poškození dat. Například:

• Vrací po opakovaném přečtení stále stejná data? I po power cycle?
• Liší se chybná data pár bitflipy, nebo je to nějaké totální smetí?
• Pokus o další investigaci: kdy byl postižený blok zapsán, jestli už byl od té doby úspěšně přečten, nebo jsme ho už špatně zapsali. Pokud o zjištění jestli jsme ho už neposlali poškozený disku (chyba RAM, SW).

Řekl by Ext4 vůbec něco? Jestli jo, tak kdy přesně? Za uherský rok, až příslušný kousek metadat bude náhodou potřeba? Nebude pozdě? Nemělo už být zařízení nahrazené hovnovým?

Řekl by to při svém scrubu. Tedy při přečtení celého disku. V případě MD RAIDu to mnohé distribuce dělají automaticky jednou měsíčně (cronjob pro echo check > /sys/block/mdX/md/sync_action), případě jednoho disku si to můžeš dát do cronu stejně jako sis dal ten scrub.

A co kdyby se tohle stalo v datech? Řekl by Ext4 na férovku, že ta data už prostě nemá, nebo by nenápadně vracel náhovné smetí? Smetí! Vracel by smetí.

Ne, nevracel by smetí, vrátil by read error (byl reportovaný diskem), stejně jako se to stalo btrfs (a ten pak měl druhou kopii kterou obnovil).

[karkar]

Ale to právě když ti vrátí read error tak není ta silent data corruption, ne? To silent přece znamená, že se ti někde překlopila 1 na 0 a ty o tom nevíš, žádnej read error to nevyhodí.

[Andrej]

V případě MD RAIDu…

Nic takového neexistuje. AID není RAID.

…a ten pak měl druhou kopii kterou obnovil…

Výborně. Pomalu, ale jistě si to začínáš uvědomovat. Pokrok…!

[PetebLazar]

Chcete tvrdit, že RAID156 sw/hw neposkytne čitelná data v případě výskytu nečitelného sektoru (Read Error) na jednom z jeho členů?

Jedna věc je být oslněn pokročilou technologií, druhá ignorovat skutečnost.

[Michal]

Pokud jsou v MD RAID1 data čitelbá, ale corruptlá (v každé kopii jiná), tak to vráti náhodně jednu z verzí. Vyzkoušeno. RAID1 nečte obě kopie. Stejně by nevěděl, která je správně

[PetebLazar]

" v případě výskytu nečitelného sektoru (Read Error) " Tj. situace, kdy jediná chyba k níž o počátku věků na storage došlo se týká právě toho daného nečitelného sektoru (nevím jak to formulovat, aby to bylo pochopitelné). Šlo mi pouze o redundanci vůči tomuto druhu chyb nic více ani méně.

Pokud takový případ jak Vy popisujete nastane (a Vaše aplikace si z nesrozumitelných dat v souboru dělá hlavu) tj. prakticky všechny dnešní programy využívající nějakou vnitřní kompresi či checksumming (např. DB) vždy máte možnost zkusit RAID pole namountovat readonly v degradovaném stavu bez jednotlivých memberů a na několik pokusů zkusit vykopírovat data ve stavu kdy jsou OK. Samozřejmě ti největší smolaři mezi námi mohou vyhrát loterii se vznikem dvou a více SDC v jednu chvíli v rámci jednoho stripe na více memberech.

Jak se můžete dočíst v diskusi níže je tu mnou vyjádřená doměnka, že když dojde k SDC u vypočteného checksumu bloku v RAM před jeho zapsáním na storage, BTRFS později odmítne vrátit data bloku jež jsou perfektně čitelná a bez SDC. Jediný mě zatím známý postup jak se dostat k datům je přepnout filesystém do ignorechecksum režimu, což bych přirovnal k postupu výše. Prohlásíme kvůli tomu BTRFS za filesystém bez redudance (protože nezpočítal checksum ve dvou nezávislých kopiích různými nezávislými prostředky)? Nikoli, jde pouze o jednu z implementací FS s neúplnou redundancí (stále patrně obsahující minimálně jeden či více single point of failure).

PS: Možná se pletu a BTRFS/ZFS a další podobné FS mají všechny své kroky redundantní, v tom případě se omlouvám. Z dodavadních rozhořčených reakcí věrozvěstů těchto FS při podobném dotazu v minulosti jsem nabyl dojmu, že tomu tak patrně není (či oni sami vlastně netuší jak to vlastně funguje), v opačném případě by předpokládám na dotaz odpověděli.

[Aleš Kapica]

PS: Možná se pletu a BTRFS/ZFS a další podobné FS mají všechny své kroky redundantní, v tom případě se omlouvám.

Nevím, jestli mne řadíš mezi věrozvěsty, ale opakovaně jsem zmiňoval, že u Btrfs je to tak, jak si to uděláš. V single mode jsou duplikovaná pouze metadata. A pokud do toho FS přidáš další disky dodatečně, musíš implicitně říct aby se stávající věci dostaly také na další disky.

Pro srovnání. Stroj, u kterého se po eventuálním selhání nvme disku budou data obnovovat z image:

~# btrfs fi usage /
Overall:
    Device size:                 873.27GiB
    Device allocated:            272.02GiB
    Device unallocated:          601.24GiB
    Device missing:                  0.00B
    Device slack:                    0.00B
    Used:                        215.27GiB
    Free (estimated):            651.98GiB      (min: 351.36GiB)
    Free (statfs, df):           651.98GiB
    Data ratio:                       1.00
    Metadata ratio:                   2.00
    Global reserve:              305.25MiB      (used: 0.00B)
    Multiple profiles:                  no

Data,single: Size:260.01GiB, Used:209.27GiB (80.49%)
   /dev/nvme0n1p3        260.01GiB

Metadata,DUP: Size:6.00GiB, Used:3.00GiB (50.03%)
   /dev/nvme0n1p3         12.00GiB

System,DUP: Size:8.00MiB, Used:48.00KiB (0.59%)
   /dev/nvme0n1p3         16.00MiB

Unallocated:
   /dev/nvme0n1p3        601.24GiB

A můj notebook, u kterého se v takovém případě vymění chcíplý disk za jiný:

~# btrfs fi usage /
Overall:
    Device size:                   1.79TiB
    Device allocated:              1.76TiB
    Device unallocated:           29.38GiB
    Device missing:                  0.00B
    Device slack:                    0.00B
    Used:                          1.58TiB
    Free (estimated):            105.01GiB      (min: 105.01GiB)
    Free (statfs, df):           105.01GiB
    Data ratio:                       2.00
    Metadata ratio:                   2.00
    Global reserve:              512.00MiB      (used: 0.00B)
    Multiple profiles:                  no

Data,RAID1: Size:894.00GiB, Used:803.67GiB (89.90%)
   /dev/sdb1     894.00GiB
   /dev/sda1     894.00GiB

Metadata,RAID1: Size:7.00GiB, Used:3.96GiB (56.63%)
   /dev/sdb1       7.00GiB
   /dev/sda1       7.00GiB

System,RAID1: Size:64.00MiB, Used:140.00KiB (0.21%)
   /dev/sdb1      64.00MiB
   /dev/sda1      64.00MiB

Unallocated:
   /dev/sdb1      14.69GiB
   /dev/sda1      14.69GiB

[PetebLazar]

Pokud bude pouze jeden zdroj (jediný prvotní výpočet) checksumu a v něm vznikne před uložením (či při jeho výpočtu) chyba nezmění na výsledném stavu FS ani deset jejich kopii na discích.

[jk001]

Bych cekal, ze na tenhle read error vyhodi ext4 IO error a prehodi ten filesystem do read-only. Ty metadata by byly ztraceny, poskozeni tezko odhadnout, stejne tak reakci fsck.

Nedovedu si moc predstavit, ze by to bylo "silent" a vracelo to nahodny balast.

[Apfelstrudl]

Tomu vasemu zargonu moc nerozumim ale tyka se to i osvicenych uzivatelu SSD s APFS?

[Max]

Tak APFS je CoW podobně jako BTRFS, má to checksummy apod. (ale asi ne dat jako to má btrfs), takže chování u APFS by mělo být obdobné jako u BTRFS. Nicméně neznám implementaci a nemám ani zkušenost, podobně jako nemám zkušenost s ReFS u Windows.
Zdar Max

[T@fu]

A co ti v tom brani vyhodit linuxa a poridit si poradny desktop s jablickem?

[PetebLazar]

Má kromě Apple Pro vůbec nějaké současné Apple zařízení (MacBook Pro, Mac Studio, iMac, Mac Mini) schopnost redundance storage?

[RealJ]

Interni storage? Ne. Externi? Ano. Pouzivam denne jiz nekolik let.

[PetebLazar]

Předpokládám, že je teoreticky možné rozdělit jednu interní fyzickou storage na dvě logické a zrcadlit data mezi nimi. Nebude to sice mít redundanci na úrovně řadiče (asi ani flash chipů), ale aspoň na úrovni flash cell. Díky krátkým přístupovým dobám a sekvenčním rychlostem by to asi nemělo ani velký dopad na výkon běžných aplikací.

[Max]

Já bych to nepředpokládal, resp. bych předpokládal, že Apple to vždy dělá přes celý disk. Resp. aspoň ten wizard má myslím jen výběr hdd. Ale třeba z cmd to půjde jinak. Každopádně tato snaha je ohýbat něco, co Apple oficiálně asi nechce. To jsme tedy u toho, že si člověk vybere řešení, které mu nevyhovuje a pak se ho snaží ohýbat, což většinou končí špatně.
Zdar Max

[PetebLazar]

Takový Mach.2 Multi-Actuator by byl asi ideálním HDD pro takovou šílenost, se dvěma nezávislými mechanismy hlav. V SAS provedení se HDD jeví řadiči jako dva device, u SATA modelů jde z pohledu řadiče o jedno zařízení s tím, že "hranice kompetencí mechanismu hlav" vede v polovině kapacity.

https://www.seagate.com/innovation/multi-actuator-hard-drives/

[RealJ]

A teoreticky je mozne poskrabat se na koulich svym jazykem… ale proc bych to delal…

[Aleš Kapica]

No je vidět že máš páteř hezky pružnou a ohebnou. Mne by něco takového nenapadlo ani ve snu a i kdyby jo, stejně bych to nedal.

[PetebLazar]

To je holt vidět kam až vede uzavřený ekosystém, lidé hledají uspokojení svých potřeb ve zcela jiných oblastech.

[~]

Z meho pozorovani okoli jsou uzavreni predevsim linuxaci. Jablickar ma doma jak macy tak widle tak tucnaky. A i nejakou konzoli. Linuxak je zavrenej v GNU kleci a na konkurenci nesahne z nabozenskych duvodu, byt ma desktop v srackach, notas co neumi spat, mobil z praveku a hodinky s vydrzi v minutach. Hlavne ale free!

[Aleš Kapica]

Z meho pozorovani okoli jsou uzavreni predevsim linuxaci. Jablickar ma doma jak macy tak widle tak tucnaky. A i nejakou konzoli. Linuxak je zavrenej v GNU kleci a na konkurenci nesahne z nabozenskych duvodu

To se tedy kardinálně pleteš. Linuxák se na rozdíl od tebe nemusí rochnit až po lokty v septiku.

[RealJ]

Njn, ma na to pracovni kumbal po uklizecce… se mas cim chlubit, Alesi…

[Aleš Kapica]

Jsi mi ale jelito. Vždyť nemáš ani páru, co je to kumbál. Hned bych ho vyměnil za ten náš skleník.

[Jendа]

notas co neumi spat

Kde se tenhle mem furt bere? Všechny notebooky co jsem měl spát uměly: od lowend a middleend asusů přes HP ProBooky po ThinkPad. I u kolegů jsem na žádné takové problémy nenarazil. Jediný problém ever jsem měl s Asusem v roce 2012, a brzy to bylo opraveno v novém kernelu.

[Martin Tůma]

Tak uspat se uměl každý NB co jsem měl za posledních 15 let v ruce, ale ne všechny se uměly bez problémů probudit . Pravda ale je, že dnes už se člověk musí fakt snažit na takovej narazit.

[Max]

Prý to vyžaduje odoperování části žeber, ale těžko říci, jakou máš k tomu predispozici :). Já bych si mohl olíznout maximálně tak kolena :)
Zdar Max

[Aleš Kapica]

Tvl Maxi, ty jsi úplný jogín! Já se o to pokusit, tak si přelomím páteř i játru.

[RealJ]

Maxi, zeru furt steaky, chlastam furt alkohol, pohyb mam maximalne do garaze do auta, takze si oliznu leda tak… vymyslet picoviny typu rozdeleni interniho storage na 2 oddily abych nad tim postavil jakoukoliv picovinu mi prijde fakt jako totalni picovina. Ale treba se pletu a mam to zkusit, treba me to v necem prekvapi…

[Aleš Kapica]

Typický trupoš. Nejvyšší čas, aby tě doprovodili tam kam patříš.

[Max]

V tom nemáme rozpor :), jen jsem technicky rozvedl tvůj vtípek :)
Zdar Max

[PetebLazar]

V případě podpory RAID1 nad partitions může být této redundance dosaženo jen nad částí celkové kapacity pro zvýšení dostupnosti/spolehlivosti pro kritická data. Redundance dat na jediném device není nic neobvyklého a je tu s námi dekády, například již filesystém FAT12 měl zdvojenou file allocation table. FAT12_overview.pdf

[RealJ]

"pro zvýšení dostupnosti/spolehlivosti pro kritická data" - neco jako si psat poznamky 2x na stejny papir a pak brecet kdyz ti ho zena vyhodi...

[PetebLazar]

Čemu na

Nebude to sice mít redundanci na úrovně řadiče (asi ani flash chipů), ale aspoň na úrovni flash cell

nerozumíte, pokusím se to vysvětlit jednodušeji?

[RealJ]

Petre, ja se s tebou do diskusi jiz nepoustim, nikam to nevede. Pripominas mi Dannyho z lupy/rootu, ten ma taky vzdy pravdu, ironii nechape a vsude byl a vsechno zna i kdyz o tom vi uplny hovno.

[PetebLazar]

A přesto máte nutkavou potřebu reagovat na většinu mých příspěvků. Víte, že je tu možnost schovat příspěvky konkrétních autorů?

[Max]

Já jsem s výkonem svého desktopu spokojený. A ano, běží mi tam i MACOS, ve virtualizaci, kvůli testování konfigurací apod. pro road warriory.
Apple navíc nepodporuje takovou sadu sw jako Linux a nemá takové možnosti jako např. btrfs. Dřív jsem přemýšlel nad MAC Bookem, ale nakonec jsem to zavrhl, jelikož potřebuji být flexibilní a neomezovat se jen na jeden OS.
Zdar Max

[RealJ]

Apfs sice nema features jako zfs nebo btrfs ale umi spoustu veci vcetne snapshotu a komprese. Akorat k tomu nemas hezke UI.

[Max]

No, oproti btrfs má šifrování v sobě, ale zase nemá checksum na datech. A nevím, jak je řešen ten RAID0/RAID1, zda pomocí APFS, nebo je pod tím ještě nějaká jiná vrstva. Možná čas si to ve VM vyzkoušet, místo teoretizování :)
Zdar Max

[Martin Tůma]

To je pokus o naboostování tvého CV až se budeš ucházet o práci titulkáře pro iDNES?

Vždyť v tom textu je přesný opak toho "silent" v sousloví "silent data corruption"! I/O error z kernelu opravdu není "silent" a spíš podporuje přesný opak, tedy tezi, že prakticky každý moderní HW má dneska nějaké interní kontrolní součty a se skutečným "silent data corruption" se tak běžný uživatel prakticky nemá šanci setkat...

[PetebLazar]

Na druhou stranu až si někdo vygůglí za pár týdnů frázi "silent data corruption" vrátí mu to více výsledků než včera a to bez ohledu na jejich relevanci.

Zde mi to podle výpisu přijde jako chyba čtení na úrovni block device (nvme) a to ještě před tím než se data vůbec dostala do rukou filesystému. https://lore.kernel.org/all/yq1fsqvq4re.fsf@ca-mkp.ca.oracle.com/T/

[Andrej]

To nepochopení zjevného jen předstíráš, nebo to fakt myslíš vážně? To snad ne, tohleto…

Když někde bouchne plyn, je to docela hluk, co?

Ten únik plynu, který tam byl týden, byl tichá hrozba nebo ne…?

Ještě jinak: Ta (meta)data fakt zmizela až v momentě té hlášky, přesně v tomtéž Planckově čase?

Nezmizela náhodou už o trochu dřív, potichu? Naštěstí si scrub toho zmizení „všiml“.

[Martin Tůma]

Pokud se k těm datům nepřistupuje, je úplně irelevantní, že jsou neplatná/"zmizelá" a kdy se tak stalo. Zásadní je, že v okamžiku, kdy se k nim přistupuje se o tom problému dozvíš (a nevalidní data nepoužiješ) a to se tady stalo. A stalo se to ne proto, že by to odhalil tvůj milovaný BTRFS za pomoci svých kontrolních součtů, ale proto, že to odhalil HW pomocí svých vlastních kontrolních součtů.

Než tady začneš ostatní poučovat o "Planckově čase", možná by nebylo od věci si nastudovat základní termíny jako co to takový "silent data corruption" vlastně je...

[Vrchní anonymní šulin]

Můžeš mi Andreji vysvětlit jak tohle může být silent data corruption, když v logu jasně vidím:

Mar 03 22:56:52 kernel: critical medium error, dev nvme1n1, sector 79051136 op 0x0:(READ) flags 0x0 phys_seg 110 prio class 3

To je kurva hlasitý problém. A přesně to samé dostanu, když na tom disku budu mít i ext4.

Příště bych skutečně viděl rád ten silent. Neboli poškozená data a nikde žádná hláška o chybě a až ten spásný BTRFS to opraví.

[Andrej]

Tak tohle je ovšem nepochopení level ULTIMATE.

Bez scrubu by se to poškození zjistilo JAK? (A kdy? Včas asi ne…)

A přesně to samé dostanu, když na tom disku budu mít i ext4.

Jenže neopraví se to. Konec, šmitec, je to v prdeli. A odhalí se to až ve chvíli, kdy už těch selhání bude nekonečno a opravovat už nebude co ani jak.

Btrfs rulezzz.

[Martin Tůma]

Bez scrubu by se to poškození zjistilo JAK? (A kdy? Včas asi ne…)

Při čtení dat za pomoci I/O chyby z kernelu, ten "magický" scrub není nic jiného, než "obyčejné" čtení disku. Což je z hlediska integrity dat včas.

[PetebLazar]

Nedohledal jsem zda BTRFS počítá všechny checksumy a jejich kopie (při ukládání dat i při čtení) redundantně (maximálně nezávislými zdroji CPU), protože pokud ne je tu nenulové riziko že díky nahodilé chybě CPU při vzniku a uložení takového checksumu dojde později k "falešně pozitivní detekci SDC", tj. bude nahlášen nesoulad uloženého checksumu s daty jež jsou z IO pohledu čitelná a k silent data corruption u nich nedošlo (správná data by pak patrně aplikací takového checksumu byla "opravena" na chybná ve snaze korigovat domnělou SDC chybu).

[PetebLazar]

Zkusil jsem vytvořit BTRFS filesystém na 2GB partition s checksum sha256 a umístil na něj cca 100KB soubor plný "@", jelikož velikost bloku byla 4KB vytvořil jsem si menší 4KB soubor plný @ s spočítal jeho sha256sum.

Z odmountované partition jsem si vyrobil img a dal jej prohledat hex. na vyskyt daneho checksumu a opravdu nalezl jsem 24 zaznamu s tímto checksumem pro každý ze 24 bloků souboru a to podle umístěné v img ve dvou lokacích (předpokládám redundatní záznamy checksumů bloku cca 100MB od sebe vzdálené).

Zkusil jsem flipnout bit u jednoho z checksumu bloku, BTRFS to detekoval a použil předpokládám mirror záznamu checksumu bloku (kterému checksumy vyššího levelu seděly?)

[ 4327.787369] BTRFS: device fsid 50b1b947-8087-49f8-ada4-21619e97b7af devid 1 transid 9 /dev/sdb1 scanned by mount (36446)
[ 4327.795452] BTRFS info (device sdb1): first mount of filesystem 50b1b947-8087-49f8-ada4-21619e97b7af
[ 4327.795485] BTRFS info (device sdb1): using sha256 (sha256-ni) checksum algorithm
[ 4327.795497] BTRFS info (device sdb1): using free-space-tree
[ 4327.803383] BTRFS warning (device sdb1): checksum verify failed on logical 30654464 mirror 1 wanted 0x29c7ecd134d77aa328376cd449e723f7cf2f41e8d006ea09d475a848c4dbc7ab found 0x1f0155c23bd1c14a4438c1b46e8d9ec9afe054ba7dec1735599321edc4bfafab level 0
[ 4327.804399] BTRFS info (device sdb1): read error corrected: ino 0 off 30654464 (dev /dev/sdb1 sector 76256)
[ 4327.804687] BTRFS info (device sdb1): read error corrected: ino 0 off 30658560 (dev /dev/sdb1 sector 76264)
[ 4327.805132] BTRFS info (device sdb1): read error corrected: ino 0 off 30662656 (dev /dev/sdb1 sector 76272)
[ 4327.805440] BTRFS info (device sdb1): read error corrected: ino 0 off 30666752 (dev /dev/sdb1 sector 76280)

[PetebLazar]

Pokud jsem flipnul bit v obou checksum záznamech bloku (snaha o simulaci chybného výpočtu checksumu před zápisem bloku) vypadá to, že BTRFS se z toho nevpamatuje.

[ 6653.301383] BTRFS: device fsid 50b1b947-8087-49f8-ada4-21619e97b7af devid 1 transid 9 /dev/sdb1 scanned by mount (36954)
[ 6653.305375] BTRFS info (device sdb1): first mount of filesystem 50b1b947-8087-49f8-ada4-21619e97b7af
[ 6653.305398] BTRFS info (device sdb1): using sha256 (sha256-ni) checksum algorithm
[ 6653.305407] BTRFS info (device sdb1): using free-space-tree
[ 6653.319499] BTRFS warning (device sdb1): checksum verify failed on logical 30654464 mirror 1 wanted 0x29c7ecd134d77aa328376cd449e723f7cf2f41e8d006ea09d475a848c4dbc7ab found 0x1f0155c23bd1c14a4438c1b46e8d9ec9afe054ba7dec1735599321edc4bfafab level 0
[ 6653.320077] BTRFS warning (device sdb1): checksum verify failed on logical 30654464 mirror 2 wanted 0x29c7ecd134d77aa328376cd449e723f7cf2f41e8d006ea09d475a848c4dbc7ab found 0x1f0155c23bd1c14a4438c1b46e8d9ec9afe054ba7dec1735599321edc4bfafab level 0
[ 6653.320153] BTRFS error (device sdb1: state C): failed to load root csum
[ 6653.322065] BTRFS error (device sdb1: state C): open_ctree failed
[ 6663.750473] /mnt/sdb1: Can't lookup blockdev

Takže přesto, že samotná data jsou čitelná BRTFS je defaultně asi z opatrnosti nezpřístupní.

Vypadá to, že namoutování s ignorováním checksumu v ro umožní se k datům aspoň dostat. sudo mount -o ro,rescue=ignoredatacsums /dev/sdb1 /mnt/sdb1/

Vy co BTRFS používáte, existuje postup, který dá checksumy do souladu s daty (bez ohledu na případné riziko SDC)? Vypadá to, že v ro rescue mount či při odmoutování se btrfs scrub okamžitě zastaví.

[Aleš Kapica]

Zkusil jsem vytvořit BTRFS filesystém na 2GB partition..

Nevím co k tomu dodat. Když jsem před mnoha lety prováděl podobné hrátky, ukázalo se prakticky, že Btrfs pod 2GB má smysl leda pro takové pokusy.

Ve tvých pokusech vidím pouze /dev/sdb1 a tak nechápu co se pokoušíš sdělit, protože logika věci je úplně jinde. Spolehlivost FS je dána blokovým zařízením nad kterým běží. Když máš Btrfs v single mode nad MD raidem, spoléháš de facto na ten MD raid.

Rozdíl spočívá v tom, že pokud se objeví chyba blokovém zařízení MD raidu, rozhoduje MD raid, který blok je správný a který ne. Btrfs s tím nic nenadělá. Chybějící data – byť jsou teoreticky k dispozici – nevyčaruje. Ale pokud má přímý přístup k zařízení a narazí na chybu, uloží rovnou kopii jinam. Nežongluje s celým blokovým zařízením, protože to není třeba. Řeší jen ten konkrétní blok, jehož se to týká. V single mode nemá odkud data obnovit, takže vychází z logiky – než vypisovat blbosti, tak raději nevracet nic. Kéž by se takovou logikou řídili i zdejší mudrlanti.

[PetebLazar]

Data jsou v pořádku, pouze jejich checksum nikoli (simulace chybně spočítaných a uložených checksumů). Má otázka zní jsem schopen docílit toho, aby BTRFS filesystém narovnal checksumy podle čitelných "užitečných" dat (ignoroval stav chybných checksumů a spočítal uložil je znovu)?

[Aleš Kapica]

Data jsou v pořádku, pouze jejich checksum nikoli

Taková situace za normálních okolností nesmí nikdy nastat. Pokud nastane, řeší to Btrfs tím, že vadný chunk zahodí a vyhodí chybu. Není sebemenší důvod k nějakému „narovnávání”. Btrfs neřeší, jestli chyba nastala v důsledku vadného disku, RAM, nebo tvé „zvídavosti”.

Pokud se totiž něco takového děje, je to signál, že ve tvém systému něco hnije a je potřeba to urychleně řešit.

[PetebLazar]

Takže BTRFS připouští možnost SDC v rámci storage(IO), ale nepřipouští si ho v rámci CPU/RAM? Asi i jejich strach z SDC své meze.

[Want]

Co to meleš? Celé je to o tom, jak přistupovat k chybě když se objeví. Btrfs není FS, který by se snažil něco domýšlet, protože neví je-li to chybou RAM nebo blokového zařízení. Validní blok vrací uložený checksum. Pokud to nesedí, je datový blok vadný. Tečka. Metadata jsou duplikovaná a pravděpodobnost, že by dva checksumy byly poškozené tak aby byly stejné je téměř nula. A pak je tu datový blok, jemuž ten checksum musí odpovídat.

A když jich má víc, tak se mezi nimi minimálně jeden vyhovující nepochybně najde.

[PetebLazar]

Pokud dojde k chybě v neredundatním výpočtu checksumu bloku žádný počet uložených kopií checksumů s tím nic nenadělá.

I bezchybná data budou na základě toho označena za chybná. Checksum tedy má pravdu, i když pravdu nemá.

[Aleš Kapica]

Nechápu o co se snažíš. Pointa je jinde. Ptal ses: Vy co BTRFS používáte, existuje postup, který dá checksumy do souladu s daty (bez ohledu na případné riziko SDC)?, ale odpověď tě nezajímá. A tvé pozorování je vskutku „objevné”:

Vypadá to, že v ro rescue mount či při odmoutování se btrfs scrub okamžitě zastaví.

Je totiž jasné, že se pokud se udělá rescue mount, tak nejspíš proto, že NECHCEŠ aby se na tom FS z jakéhokoliv důvodu dály nějaké změny. A scrub DĚLÁ změny, ale JEN KDYŽ MŮŽE. Na práci s odmountovaným FS má btrfs jiné nástroje. Změny které dělá scrub jsou totiž nedestruktivní a probíhají na pozadí. Stejně jako když pustíš balancing, atp.

Přijde mi absolutně nelogické, aby zůstal v běhu i poté co se FS odpojí. Většinou se totiž disk odpojuje když ho chceš vyndat, nebo ten stroj vypnout.

[PetebLazar]

V tuto chvíli to beru tak, že postup (příkaz) na repair FS z tohoto stavu neznáte, či neexistuje, nepředpokládám že byste ho odmítal sdělit.

Namountování ro,rescue(ignorování checksumu) a vykopírování obsahu na jiný funkční filesystém mi jako workaround stačí.

[Aleš Kapica]

Používám Btrfs všude možně v nejrůznější konstelaci víc jak 13 let a nikdy jsem to nepotřeboval. A to jsem zažil i chvíle, kdy mi opravdu hodně lepilo u zadku. O data jsem za ty roky přišel pouze jednou – díky Ext4. Nedošlo by k tomu, kdybych měl nad tím MD raidem měl Btrfs.

[PetebLazar]

Pravděpodobnost takovýchto chyb poroste s intezitou/objemem zápisů na FS, s převážně read-oriented zátěží se s tím člověk asi nemusí potkat vůbec vzhledem k obecné pravděpodobnosti takového jevu. Případný flip v paměti při čtecí operaci by musel postihnout současně obsah všech kopií checksumů v paměti (pravděpodobnost asi rovna kladné nule), či kombinovat flip v jedné kopie checksumu v paměti se současnou chybou čtení dalších kopií checksumu.

[Want]

Tak pravdou je, že se můj kolega s problémy setkal. Na stejném stroji, který jsem předtím několik let s Btrfs bez problému provozoval (byl jedním z bodů sheepdogu). A používám ho i teď - opět bez problému.

Rozdíl je především v tom, jak to Btrfs nasadil. Já používám multidevice mód. On vsadil na HW raid, a Btrfs měl v single módu. To podle mne nikdy nemohlo dopadnout dobře. Obzvláště když nad tím provozoval OpenNebulu.

Já na tom provozuji NFS pro disklessovou infrastrukturu. Exporty jsou až na výjimky RO, protože kraviny se zapisují u všech strojů do RAM a uživatelská data se ukládají na Netapp. Tou výjimkou je virtuální cca 40GB lokální keš, formátovaná také na Btrfs.

[PetebLazar]

Nějaká historická studie IBM (z 90tých) zmiňovala pravděpodobnost flipu bitu paměti vlivem kosmického záření pro objem paměti 256MB jednou za měsíc (1x při expozici paměti 663 552 000 MB.s). Zápis dejme tomu 100GB při čtyřkilových blocích a životnosti checksum záznamu (od jeho výpočtu k zapsání např. 10ms) je to expozice paměti 100*10^9/4096*32/100 cca 7,8MB.s (pravděpodobnost 1/85 000 000 vzniku chyby v aspoň jednom z checksumů uloženého v RAM při zapsání 100GB). Pro každý 1TB zapsaných dat jde již o cca pravděpodobnost jako je výhra Jackpotu ve Sportce. Riziko výhry ve Sportce pro jednotlivce je relativně malé, ale lidé vyhrávají docela pravidelně.

Vzhledem ke zmenšení paměťových struktur v mezidobí a vlivu toho na flip mohou být výsledné pravděpodobnosti dnes řádově asi zcela jinde.

Šel jsem dnes spát pozdě, takže za výpočty výše neručím.

[GeorgeWH]

Skor je otazka, o co ide tebe. Pyta sa normalnu regulernu vec - ako opravit chybny checksum? Alebo, ak sa ti nepaci tato otazka, tak: ako precitat spravne ulozene data s nespravne ulozenym checksumom?

[PetebLazar]

Na přečtení dat jsem přišel

sudo mount -o ro,rescue=ignoredatacsums /dev/sdb1 /mnt/sdb1/

Šlo mi o to jestli je tento nastalý stav pro BRRFS filesystém konečnou, či je možné recovery z něj. To mi přijde jako legitimní otázka.

Význam vět o velikosti FS a to, že taková věc nesmí nastat jsem popravdě nepochopil. Pravděpodobnost flipu obsahu paměti například díky kosmickému záření je údajně daleka nule a nebude patrně záviset na kondici PC.

[Michal]

Tohle fakt není silent, ale prachsprostý beďar. Opravdový SDC je velmi vzácný. Za celou kariéru jsem se s tím setkal jen jednou. Na Adaptecu s vadnou RAM. A to mám odkrouceno několik desítek petabajtoroků.

[Ovoce]

představitel pozdního šulinismu (ježto vrcholný šulinismus už je, doufejme, dávno v propadlišti dějin)

Není třeba se bát, že by pozdní šulinismus byl předzvěstí konce. Vždycky zase přijde Neošulinismus nebo Pseudošulinismus. Přičemž ve slozích platí, že "pseudo" varianta je horší než originál.

[...]

Retardovaně se hihňáš, ale na výuku všech těhle oborů má Kolibáč atestaci.