abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
    dnes 13:11 | IT novinky

    Domén s koncovkou .CZ je už 1,5 miliónu. K registraci domény s pořadovým číslem 1 500 000 došlo včera krátce před půlnocí. Počet domén se dynamicky vyvíjí podle toho, jak jsou registrovány nebo naopak rušeny. Proto je v tuto chvíli jejich počet opět nižší.

    Ladislav Hagara | Komentářů: 0
    včera 20:44 | Nová verze

    Byla vydána beta verze Ubuntu 25.04 s kódovým názvem Plucky Puffin. Přehled novinek v poznámkách k vydání. Dle plánu by Ubuntu 25.04 mělo vyjít 17. dubna 2025.

    Ladislav Hagara | Komentářů: 0
    včera 12:11 | Nová verze

    Textový editor Neovim byl vydán ve verzi 0.11 (𝕏). Přehled novinek v příspěvku na blogu a poznámkách k vydání.

    Ladislav Hagara | Komentářů: 4
    včera 05:00 | Komunita

    Živé ISO obrazy Debianu Bookworm jsou 100 % reprodukovatelné.

    Ladislav Hagara | Komentářů: 1
    26.3. 13:44 | Zajímavý článek

    Boudhayan "bbhtt" Bhattcharya v článku Uzavření kapitoly o OpenH264 vysvětluje, proč bylo OpenH264 odstraněno z Freedesktop SDK.

    Ladislav Hagara | Komentářů: 6
    26.3. 03:44 | IT novinky

    Představeny byly nové verze AI modelů: DeepSeek V3-0324, Google Gemini 2.5 a OpenAI 4o Image Generation.

    Ladislav Hagara | Komentářů: 0
    26.3. 03:11 | Nová verze

    XZ Utils (Wikipedie) byly vydány ve verzi 5.8.0. Jedná se o první větší vydání od backdooru v XZ v loňském roce.

    Ladislav Hagara | Komentářů: 0
    25.3. 20:33 | Nová verze

    Byla vydána nová verze 0.40.0 multimediálního přehrávače mpv (Wikipedie) vycházejícího z přehrávačů MPlayer a mplayer2. Přehled novinek, změn a oprav na GitHubu. Požadován je FFmpeg 6.1 nebo novější a také libplacebo 6.338.2 nebo novější.

    Ladislav Hagara | Komentářů: 71
    25.3. 14:11 | Nová verze

    Byla vydána nová verze 2.20 svobodného video editoru Flowblade (GitHub, Wikipedie). Přehled novinek v poznámkách k vydání. Videoukázky funkcí Flowblade na Vimeu. Instalovat lze také z Flathubu.

    Ladislav Hagara | Komentářů: 0
    25.3. 04:22 | Nová verze

    LibrePCB, tj. svobodný multiplatformní softwarový nástroj pro návrh desek plošných spojů (PCB), byl vydán ve verzi 1.3.0. Přehled novinek v příspěvku na blogu a v aktualizované dokumentaci. Vypíchnut je interaktivní HTML BOM (Bill of Materials) a počáteční podpora Rustu. Zdrojové kódy LibrePCB jsou k dispozici na GitHubu pod licencí GPLv3.

    Ladislav Hagara | Komentářů: 0
    Jaké je vaše preferované prostředí?
     (29%)
     (1%)
     (1%)
     (2%)
     (1%)
     (1%)
     (62%)
     (2%)
    Celkem 244 hlasů
     Komentářů: 10, poslední 24.3. 12:37
    Rozcestník

    Silent Data Corruption NEEXISTUJE!

    4.3. 00:49 | Přečteno: 1254× | 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:

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

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

           

    Hodnocení: 100 %

            špatnédobré        

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    4.3. 01:45 karkar | skóre: 8 | blog: Kartrolling
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    Fakt si do dostal zhovna?
    4.3. 01:46 karkar | skóre: 8 | blog: Kartrolling
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    tvl to je den, podělám i trolící narážku na hovna :-(

    Gréta avatar 4.3. 08:11 Gréta | skóre: 37 | blog: Grétin blogísek | 🇮🇱==❤️ , 🇵🇸==💩 , 🇪🇺==☭
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!

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

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

    Jendа avatar 4.3. 02:02 Jendа | skóre: 78 | blog: Jenda | JO70FB
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    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).
    4.3. 09:12 karkar | skóre: 8 | blog: Kartrolling
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    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í.
    9.3. 03:05 Andrej | skóre: 51 | blog: Republic of Mordor
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    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…!

    9.3. 07:34 PetebLazar | skóre: 34 | blog: l_eonardovo_odhodlani
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    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.
    12.3. 12:08 Michal
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    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ě
    12.3. 13:07 PetebLazar | skóre: 34 | blog: l_eonardovo_odhodlani
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    " 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.
    12.3. 14:50 Aleš Kapica | skóre: 52 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    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
    
    12.3. 15:35 PetebLazar | skóre: 34 | blog: l_eonardovo_odhodlani
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    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.
    4.3. 08:54 jk001
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    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.
    4.3. 09:37 Apfelstrudl
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    Tomu vasemu zargonu moc nerozumim ale tyka se to i osvicenych uzivatelu SSD s APFS?
    Max avatar 4.3. 09:47 Max | skóre: 72 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    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
    Měl jsem sen ... :(
    4.3. 19:48 T@fu
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    A co ti v tom brani vyhodit linuxa a poridit si poradny desktop s jablickem?
    4.3. 20:18 PetebLazar | skóre: 34 | blog: l_eonardovo_odhodlani
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    Má kromě Apple Pro vůbec nějaké současné Apple zařízení (MacBook Pro, Mac Studio, iMac, Mac Mini) schopnost redundance storage?
    5.3. 01:03 RealJ | skóre: 8
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    Interni storage? Ne. Externi? Ano. Pouzivam denne jiz nekolik let.
    5.3. 08:44 PetebLazar | skóre: 34 | blog: l_eonardovo_odhodlani
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    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 avatar 5.3. 08:59 Max | skóre: 72 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    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
    Měl jsem sen ... :(
    5.3. 10:40 PetebLazar | skóre: 34 | blog: l_eonardovo_odhodlani
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    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/
    5.3. 15:27 RealJ | skóre: 8
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    A teoreticky je mozne poskrabat se na koulich svym jazykem… ale proc bych to delal…
    5.3. 17:35 Aleš Kapica | skóre: 52 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!

    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.

    5.3. 18:33 PetebLazar | skóre: 34 | blog: l_eonardovo_odhodlani
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    To je holt vidět kam až vede uzavřený ekosystém, lidé hledají uspokojení svých potřeb ve zcela jiných oblastech.
    5.3. 21:54 ~
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    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!
    5.3. 22:19 Aleš Kapica | skóre: 52 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    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.

    5.3. 23:40 RealJ | skóre: 8
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    Njn, ma na to pracovni kumbal po uklizecce… se mas cim chlubit, Alesi…
    5.3. 23:57 Aleš Kapica | skóre: 52 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!

    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а avatar 6.3. 01:38 Jendа | skóre: 78 | blog: Jenda | JO70FB
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    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.
    6.3. 09:21 Martin Tůma | skóre: 39 | blog: RTFM | Praha
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    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.
    Každý má právo na můj názor!
    Max avatar 5.3. 18:30 Max | skóre: 72 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    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
    Měl jsem sen ... :(
    5.3. 21:27 Aleš Kapica | skóre: 52 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    Tvl Maxi, ty jsi úplný jogín! Já se o to pokusit, tak si přelomím páteř i játru.
    5.3. 23:45 RealJ | skóre: 8
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    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…
    5.3. 23:51 Aleš Kapica | skóre: 52 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    Typický trupoš. Nejvyšší čas, aby tě doprovodili tam kam patříš.
    Max avatar 6.3. 05:15 Max | skóre: 72 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    V tom nemáme rozpor :), jen jsem technicky rozvedl tvůj vtípek :)
    Zdar Max
    Měl jsem sen ... :(
    6.3. 09:42 PetebLazar | skóre: 34 | blog: l_eonardovo_odhodlani
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    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
    6.3. 14:32 RealJ | skóre: 8
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    "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...
    6.3. 16:27 PetebLazar | skóre: 34 | blog: l_eonardovo_odhodlani
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    Č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?
    6.3. 19:29 RealJ | skóre: 8
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    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.
    6.3. 20:04 PetebLazar | skóre: 34 | blog: l_eonardovo_odhodlani
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    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 avatar 5.3. 08:41 Max | skóre: 72 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    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
    Měl jsem sen ... :(
    5.3. 15:26 RealJ | skóre: 8
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    Apfs sice nema features jako zfs nebo btrfs ale umi spoustu veci vcetne snapshotu a komprese. Akorat k tomu nemas hezke UI.
    Max avatar 5.3. 15:53 Max | skóre: 72 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    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
    Měl jsem sen ... :(
    4.3. 11:09 Martin Tůma | skóre: 39 | blog: RTFM | Praha
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!

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

    Každý má právo na můj názor!
    4.3. 12:56 PetebLazar | skóre: 34 | blog: l_eonardovo_odhodlani
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    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/
    9.3. 03:01 Andrej | skóre: 51 | blog: Republic of Mordor
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!

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

    9.3. 07:39 Martin Tůma | skóre: 39 | blog: RTFM | Praha
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!

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

    Každý má právo na můj názor!
    4.3. 18:22 Vrchní anonymní šulin
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    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í.

    9.3. 02:55 Andrej | skóre: 51 | blog: Republic of Mordor
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!

    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.

    9.3. 07:56 Martin Tůma | skóre: 39 | blog: RTFM | Praha
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    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.

    Každý má právo na můj názor!
    9.3. 09:26 PetebLazar | skóre: 34 | blog: l_eonardovo_odhodlani
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    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).
    9.3. 10:56 PetebLazar | skóre: 34 | blog: l_eonardovo_odhodlani
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    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)
    
    9.3. 11:43 PetebLazar | skóre: 34 | blog: l_eonardovo_odhodlani
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    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í.
    9.3. 15:56 Aleš Kapica | skóre: 52 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    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.

    9.3. 16:34 PetebLazar | skóre: 34 | blog: l_eonardovo_odhodlani
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    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)?
    9.3. 21:29 Aleš Kapica | skóre: 52 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    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.

    9.3. 23:06 PetebLazar | skóre: 34 | blog: l_eonardovo_odhodlani
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    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.
    10.3. 10:40 Want
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    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.
    10.3. 12:04 PetebLazar | skóre: 34 | blog: l_eonardovo_odhodlani
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    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á.
    10.3. 15:11 Aleš Kapica | skóre: 52 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!

    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.

    10.3. 16:05 PetebLazar | skóre: 34 | blog: l_eonardovo_odhodlani
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    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čí.
    10.3. 17:21 Aleš Kapica | skóre: 52 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    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.
    10.3. 17:55 PetebLazar | skóre: 34 | blog: l_eonardovo_odhodlani
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    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.
    10.3. 19:02 Want
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!

    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.

    10.3. 20:43 PetebLazar | skóre: 34 | blog: l_eonardovo_odhodlani
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    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.
    10.3. 16:46 GeorgeWH | skóre: 42
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    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?
    10.3. 17:02 PetebLazar | skóre: 34 | blog: l_eonardovo_odhodlani
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    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.
    12.3. 12:22 Michal
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    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ů.
    4.3. 20:17 Ovoce | skóre: 16 | blog: Vyplizlo_ze_zivota
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    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.
    9.3. 09:29 ...
    Rozbalit Rozbalit vše Re: Silent Data Corruption NEEXISTUJE!
    Retardovaně se hihňáš, ale na výuku všech těhle oborů má Kolibáč atestaci.

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.