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žší.
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.
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í.
Živé ISO obrazy Debianu Bookworm jsou 100 % reprodukovatelné.
Boudhayan "bbhtt" Bhattcharya v článku Uzavření kapitoly o OpenH264 vysvětluje, proč bylo OpenH264 odstraněno z Freedesktop SDK.
Představeny byly nové verze AI modelů: DeepSeek V3-0324, Google Gemini 2.5 a OpenAI 4o Image Generation.
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.
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ší.
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.
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.
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í.
Tak fajn. To bychom měli. Popírači silent data corruption všech zemí, jděte už konečně do prdele.
Tiskni
Sdílej:
sem se teda jako šprajcla hnedka u googlení slovička 'levidelný' :D
myslimže takový slovo NEEXISTUJE :O :D :O :D
Ř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).
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…!
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
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.
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.
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.
notas co neumi spatKde 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.
Nebude to sice mít redundanci na úrovně řadiče (asi ani flash chipů), ale aspoň na úrovni flash cellnerozumíte, pokusím se to vysvětlit jednodušeji?
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...
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“.
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...
Tak tohle je ovšem nepochopení level ULTIMATE.
Bez scrub
u 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.
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.
[ 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)
[ 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 blockdevTakž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í.
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.
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.
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.
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.
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.
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.