Dotaz: BTRFS je totalne na...

[Mladý komsomolec]

BTRFS je totalne na...howno... toto nerobil ani JFS, ani EXT4 ... disk je OK!

btrfsck /dev/mapper/wd
Opening filesystem to check...
Checking filesystem on /dev/mapper/wd
UUID: --------------------------------------
[1/7] checking root items
parent transid verify failed on 1996314673152 wanted 60209 found 60173
parent transid verify failed on 1996332957696 wanted 60209 found 60173
parent transid verify failed on 1996333006848 wanted 60209 found 60173
parent transid verify failed on 1996333727744 wanted 60209 found 60173
parent transid verify failed on 1996334186496 wanted 60209 found 60173
parent transid verify failed on 1996334317568 wanted 60209 found 60173
parent transid verify failed on 1996334514176 wanted 60209 found 60173
parent transid verify failed on 1996334710784 wanted 60209 found 60173
parent transid verify failed on 1996334759936 wanted 60209 found 60173
parent transid verify failed on 1996335169536 wanted 60209 found 60173
parent transid verify failed on 1996335185920 wanted 60209 found 60173
parent transid verify failed on 1996335300608 wanted 60209 found 60173
parent transid verify failed on 1996335546368 wanted 60209 found 60173
parent transid verify failed on 1996336775168 wanted 60209 found 60173
parent transid verify failed on 1996338298880 wanted 60209 found 60173
parent transid verify failed on 1996338954240 wanted 60209 found 60173
parent transid verify failed on 1996339265536 wanted 60209 found 60173
parent transid verify failed on 1996339396608 wanted 60209 found 60173
parent transid verify failed on 1996339478528 wanted 60209 found 60173
parent transid verify failed on 1996339871744 wanted 60209 found 60173
parent transid verify failed on 1996339920896 wanted 60209 found 60173
parent transid verify failed on 1996339953664 wanted 60209 found 60173
parent transid verify failed on 1996340199424 wanted 60209 found 60173
parent transid verify failed on 1996340559872 wanted 60209 found 60173
parent transid verify failed on 1996340805632 wanted 60209 found 60173
parent transid verify failed on 1996341084160 wanted 60209 found 60173
parent transid verify failed on 1996341248000 wanted 60209 found 60173
parent transid verify failed on 1996341837824 wanted 60209 found 60173
parent transid verify failed on 1996342280192 wanted 60209 found 60173
parent transid verify failed on 1996343377920 wanted 60209 found 60173
parent transid verify failed on 1996343803904 wanted 60209 found 60173
parent transid verify failed on 1996344033280 wanted 60209 found 60173
parent transid verify failed on 1996345589760 wanted 60209 found 60173
parent transid verify failed on 1996346130432 wanted 60209 found 60173
parent transid verify failed on 1996346802176 wanted 60209 found 60173
parent transid verify failed on 1996347179008 wanted 60209 found 60173
parent transid verify failed on 1996347424768 wanted 60209 found 60173
parent transid verify failed on 1996348194816 wanted 60209 found 60173
parent transid verify failed on 1996348555264 wanted 60209 found 60173
parent transid verify failed on 1996348588032 wanted 60209 found 60173
parent transid verify failed on 1996348801024 wanted 60209 found 60173
parent transid verify failed on 1996350717952 wanted 60209 found 60173
parent transid verify failed on 1996357877760 wanted 60209 found 60173
parent transid verify failed on 1996358713344 wanted 60209 found 60173
parent transid verify failed on 1996358762496 wanted 60209 found 60173
parent transid verify failed on 1996383207424 wanted 60209 found 60173
parent transid verify failed on 1996383862784 wanted 60209 found 60173
parent transid verify failed on 1996383879168 wanted 60209 found 60173
parent transid verify failed on 1996383911936 wanted 60209 found 60173
parent transid verify failed on 1996390334464 wanted 60209 found 60173
parent transid verify failed on 1996391022592 wanted 60209 found 60194
parent transid verify failed on 1996391399424 wanted 60209 found 60173
parent transid verify failed on 1996392382464 wanted 60209 found 60173
parent transid verify failed on 1996392431616 wanted 60209 found 60173
parent transid verify failed on 1996404736000 wanted 60209 found 60173
parent transid verify failed on 1996408963072 wanted 60209 found 60157
parent transid verify failed on 1996421169152 wanted 60209 found 60173
parent transid verify failed on 1996423626752 wanted 60209 found 60173
parent transid verify failed on 1996423708672 wanted 60209 found 60173
parent transid verify failed on 1996429983744 wanted 60209 found 60173
parent transid verify failed on 1996430639104 wanted 60209 found 60173
parent transid verify failed on 1996430655488 wanted 60209 found 60173
parent transid verify failed on 1996437602304 wanted 60209 found 60173
parent transid verify failed on 1996437864448 wanted 60209 found 60173
parent transid verify failed on 1997038387200 wanted 60209 found 60174
parent transid verify failed on 1997045268480 wanted 60209 found 60174
parent transid verify failed on 1997062029312 wanted 60209 found 60174
parent transid verify failed on 1997062045696 wanted 60209 found 60174
parent transid verify failed on 1997062176768 wanted 60209 found 60174
parent transid verify failed on 1997062340608 wanted 60209 found 60174
parent transid verify failed on 1997062340608 wanted 60209 found 60174
parent transid verify failed on 1997062340608 wanted 60209 found 60174
Ignoring transid failure
parent transid verify failed on 1997063503872 wanted 60209 found 60174
parent transid verify failed on 1997063634944 wanted 60209 found 60174
parent transid verify failed on 1997064454144 wanted 60209 found 60174
parent transid verify failed on 1997064454144 wanted 60209 found 60174
parent transid verify failed on 1997064454144 wanted 60209 found 60174
Ignoring transid failure
parent transid verify failed on 1997074710528 wanted 60209 found 60174
parent transid verify failed on 1997107707904 wanted 60209 found 60174
parent transid verify failed on 1997117849600 wanted 60209 found 60174
parent transid verify failed on 1997117865984 wanted 60209 found 60174
parent transid verify failed on 1997117931520 wanted 60209 found 60174
parent transid verify failed on 1997119029248 wanted 60209 found 60174
parent transid verify failed on 1997119029248 wanted 60209 found 60174
parent transid verify failed on 1997119029248 wanted 60209 found 60174
Ignoring transid failure
parent transid verify failed on 1997142802432 wanted 60209 found 60174
parent transid verify failed on 1997142818816 wanted 60209 found 60174
parent transid verify failed on 1997148356608 wanted 60209 found 60174
parent transid verify failed on 1997148667904 wanted 60209 found 60174
parent transid verify failed on 1997155221504 wanted 60209 found 60174
parent transid verify failed on 1997161922560 wanted 60209 found 60174
parent transid verify failed on 1997172785152 wanted 60209 found 60174
parent transid verify failed on 1997172785152 wanted 60209 found 60174
parent transid verify failed on 1997172785152 wanted 60209 found 60174
Ignoring transid failure
parent transid verify failed on 1997177782272 wanted 60209 found 60174
parent transid verify failed on 1997178257408 wanted 60209 found 60174
parent transid verify failed on 1997178339328 wanted 60209 found 60174
parent transid verify failed on 1997178355712 wanted 60209 found 60174
parent transid verify failed on 1997178814464 wanted 60209 found 60174
parent transid verify failed on 1997178814464 wanted 60209 found 60174
parent transid verify failed on 1997178814464 wanted 60209 found 60174
Ignoring transid failure
parent transid verify failed on 1997179092992 wanted 60209 found 60174
parent transid verify failed on 1997179092992 wanted 60209 found 60174
parent transid verify failed on 1997179092992 wanted 60209 found 60174
Ignoring transid failure
parent transid verify failed on 1997183156224 wanted 60209 found 60174
parent transid verify failed on 1997183156224 wanted 60209 found 60174
parent transid verify failed on 1997183156224 wanted 60209 found 60174
Ignoring transid failure
parent transid verify failed on 1997185417216 wanted 60209 found 60174
parent transid verify failed on 1997185449984 wanted 60209 found 60174
parent transid verify failed on 2951790542848 wanted 60209 found 60174
parent transid verify failed on 2951994163200 wanted 60209 found 60196
parent transid verify failed on 2951994179584 wanted 60209 found 60196
parent transid verify failed on 2951994294272 wanted 60209 found 60196
parent transid verify failed on 2951994310656 wanted 60209 found 60174
parent transid verify failed on 2951997243392 wanted 60209 found 60174
parent transid verify failed on 2951997276160 wanted 60209 found 60174
parent transid verify failed on 2951997341696 wanted 60209 found 60196
parent transid verify failed on 2951997390848 wanted 60209 found 60196
parent transid verify failed on 2952183742464 wanted 60209 found 60197
[2/7] checking extents
parent transid verify failed on 1997062340608 wanted 60209 found 60174
Ignoring transid failure
parent transid verify failed on 1997172785152 wanted 60209 found 60174
Ignoring transid failure
parent transid verify failed on 1997172785152 wanted 60209 found 60174
Ignoring transid failure
parent transid verify failed on 1997062340608 wanted 60209 found 60174
Ignoring transid failure
parent transid verify failed on 1997064454144 wanted 60209 found 60174
Ignoring transid failure
parent transid verify failed on 1997178814464 wanted 60209 found 60174
Ignoring transid failure
parent transid verify failed on 1997178814464 wanted 60209 found 60174
Ignoring transid failure
parent transid verify failed on 1997178814464 wanted 60209 found 60174
Ignoring transid failure
parent transid verify failed on 1997178814464 wanted 60209 found 60174
Ignoring transid failure
parent transid verify failed on 1997179092992 wanted 60209 found 60174
Ignoring transid failure
parent transid verify failed on 1997119029248 wanted 60209 found 60174
Ignoring transid failure
parent transid verify failed on 1997172785152 wanted 60209 found 60174
Ignoring transid failure
parent transid verify failed on 1997178814464 wanted 60209 found 60174
Ignoring transid failure
parent transid verify failed on 1997179092992 wanted 60209 found 60174
Ignoring transid failure
parent transid verify failed on 1997183156224 wanted 60209 found 60174
Ignoring transid failure
parent transid verify failed on 469008384 wanted 60209 found 60185
parent transid verify failed on 469008384 wanted 60209 found 60185
parent transid verify failed on 469008384 wanted 60209 found 60185
Ignoring transid failure
Segmentation fault
root@cybervault:~# btrfsck /dev/mapper/wd18tb_data
Opening filesystem to check...
Checking filesystem on /dev/mapper/wd18tb_data
UUID: 01622313-76d6-43df-bc5a-732613339f9e
[1/7] checking root items
parent transid verify failed on 1996314673152 wanted 60209 found 60173
parent transid verify failed on 1996332957696 wanted 60209 found 60173
parent transid verify failed on 1996333006848 wanted 60209 found 60173
parent transid verify failed on 1996333727744 wanted 60209 found 60173
parent transid verify failed on 1996334186496 wanted 60209 found 60173
parent transid verify failed on 1996334317568 wanted 60209 found 60173
parent transid verify failed on 1996334514176 wanted 60209 found 60173
parent transid verify failed on 1996334710784 wanted 60209 found 60173
parent transid verify failed on 1996334759936 wanted 60209 found 60173
parent transid verify failed on 1996335169536 wanted 60209 found 60173
parent transid verify failed on 1996335185920 wanted 60209 found 60173
parent transid verify failed on 1996335300608 wanted 60209 found 60173
parent transid verify failed on 1996335546368 wanted 60209 found 60173
parent transid verify failed on 1996336775168 wanted 60209 found 60173
parent transid verify failed on 1996338298880 wanted 60209 found 60173
parent transid verify failed on 1996338954240 wanted 60209 found 60173
parent transid verify failed on 1996339265536 wanted 60209 found 60173
parent transid verify failed on 1996339396608 wanted 60209 found 60173
parent transid verify failed on 1996339478528 wanted 60209 found 60173
parent transid verify failed on 1996339871744 wanted 60209 found 60173
parent transid verify failed on 1996339920896 wanted 60209 found 60173
parent transid verify failed on 1996339953664 wanted 60209 found 60173
parent transid verify failed on 1996340199424 wanted 60209 found 60173
parent transid verify failed on 1996340559872 wanted 60209 found 60173
parent transid verify failed on 1996340805632 wanted 60209 found 60173
parent transid verify failed on 1996341084160 wanted 60209 found 60173
parent transid verify failed on 1996341248000 wanted 60209 found 60173
parent transid verify failed on 1996341837824 wanted 60209 found 60173
parent transid verify failed on 1996342280192 wanted 60209 found 60173
parent transid verify failed on 1996343377920 wanted 60209 found 60173
parent transid verify failed on 1996343803904 wanted 60209 found 60173
parent transid verify failed on 1996344033280 wanted 60209 found 60173
parent transid verify failed on 1996345589760 wanted 60209 found 60173
parent transid verify failed on 1996346130432 wanted 60209 found 60173
parent transid verify failed on 1996346802176 wanted 60209 found 60173
parent transid verify failed on 1996347179008 wanted 60209 found 60173
parent transid verify failed on 1996347424768 wanted 60209 found 60173
parent transid verify failed on 1996348194816 wanted 60209 found 60173
parent transid verify failed on 1996348555264 wanted 60209 found 60173
parent transid verify failed on 1996348588032 wanted 60209 found 60173
parent transid verify failed on 1996348801024 wanted 60209 found 60173
parent transid verify failed on 1996350717952 wanted 60209 found 60173
parent transid verify failed on 1996357877760 wanted 60209 found 60173
parent transid verify failed on 1996358713344 wanted 60209 found 60173
parent transid verify failed on 1996358762496 wanted 60209 found 60173
parent transid verify failed on 1996383207424 wanted 60209 found 60173
parent transid verify failed on 1996383862784 wanted 60209 found 60173
parent transid verify failed on 1996383879168 wanted 60209 found 60173
parent transid verify failed on 1996383911936 wanted 60209 found 60173
parent transid verify failed on 1996390334464 wanted 60209 found 60173
parent transid verify failed on 1996391022592 wanted 60209 found 60194
parent transid verify failed on 1996391399424 wanted 60209 found 60173
parent transid verify failed on 1996392382464 wanted 60209 found 60173
parent transid verify failed on 1996392431616 wanted 60209 found 60173
parent transid verify failed on 1996404736000 wanted 60209 found 60173
parent transid verify failed on 1996408963072 wanted 60209 found 60157
parent transid verify failed on 1996421169152 wanted 60209 found 60173
parent transid verify failed on 1996423626752 wanted 60209 found 60173
parent transid verify failed on 1996423708672 wanted 60209 found 60173
parent transid verify failed on 1996429983744 wanted 60209 found 60173
parent transid verify failed on 1996430639104 wanted 60209 found 60173
parent transid verify failed on 1996430655488 wanted 60209 found 60173
parent transid verify failed on 1996437602304 wanted 60209 found 60173
parent transid verify failed on 1996437864448 wanted 60209 found 60173
parent transid verify failed on 1997038387200 wanted 60209 found 60174
parent transid verify failed on 1997045268480 wanted 60209 found 60174
parent transid verify failed on 1997062029312 wanted 60209 found 60174
parent transid verify failed on 1997062045696 wanted 60209 found 60174
parent transid verify failed on 1997062176768 wanted 60209 found 60174
parent transid verify failed on 1997062340608 wanted 60209 found 60174
parent transid verify failed on 1997062340608 wanted 60209 found 60174
parent transid verify failed on 1997062340608 wanted 60209 found 60174
Ignoring transid failure
parent transid verify failed on 1997063503872 wanted 60209 found 60174
parent transid verify failed on 1997063634944 wanted 60209 found 60174
parent transid verify failed on 1997064454144 wanted 60209 found 60174
parent transid verify failed on 1997064454144 wanted 60209 found 60174
parent transid verify failed on 1997064454144 wanted 60209 found 60174
Ignoring transid failure
parent transid verify failed on 1997074710528 wanted 60209 found 60174
parent transid verify failed on 1997107707904 wanted 60209 found 60174
parent transid verify failed on 1997117849600 wanted 60209 found 60174
parent transid verify failed on 1997117865984 wanted 60209 found 60174
parent transid verify failed on 1997117931520 wanted 60209 found 60174
parent transid verify failed on 1997119029248 wanted 60209 found 60174
parent transid verify failed on 1997119029248 wanted 60209 found 60174
parent transid verify failed on 1997119029248 wanted 60209 found 60174
Ignoring transid failure
parent transid verify failed on 1997142802432 wanted 60209 found 60174
parent transid verify failed on 1997142818816 wanted 60209 found 60174
parent transid verify failed on 1997148356608 wanted 60209 found 60174
parent transid verify failed on 1997148667904 wanted 60209 found 60174
parent transid verify failed on 1997155221504 wanted 60209 found 60174
parent transid verify failed on 1997161922560 wanted 60209 found 60174
parent transid verify failed on 1997172785152 wanted 60209 found 60174
parent transid verify failed on 1997172785152 wanted 60209 found 60174
parent transid verify failed on 1997172785152 wanted 60209 found 60174
Ignoring transid failure
parent transid verify failed on 1997177782272 wanted 60209 found 60174
parent transid verify failed on 1997178257408 wanted 60209 found 60174
parent transid verify failed on 1997178339328 wanted 60209 found 60174
parent transid verify failed on 1997178355712 wanted 60209 found 60174
parent transid verify failed on 1997178814464 wanted 60209 found 60174
parent transid verify failed on 1997178814464 wanted 60209 found 60174
parent transid verify failed on 1997178814464 wanted 60209 found 60174
Ignoring transid failure
parent transid verify failed on 1997179092992 wanted 60209 found 60174
parent transid verify failed on 1997179092992 wanted 60209 found 60174
parent transid verify failed on 1997179092992 wanted 60209 found 60174
Ignoring transid failure
parent transid verify failed on 1997183156224 wanted 60209 found 60174
parent transid verify failed on 1997183156224 wanted 60209 found 60174
parent transid verify failed on 1997183156224 wanted 60209 found 60174
Ignoring transid failure
parent transid verify failed on 1997185417216 wanted 60209 found 60174
parent transid verify failed on 1997185449984 wanted 60209 found 60174
parent transid verify failed on 2951790542848 wanted 60209 found 60174
parent transid verify failed on 2951994163200 wanted 60209 found 60196
parent transid verify failed on 2951994179584 wanted 60209 found 60196
parent transid verify failed on 2951994294272 wanted 60209 found 60196
parent transid verify failed on 2951994310656 wanted 60209 found 60174
parent transid verify failed on 2951997243392 wanted 60209 found 60174
parent transid verify failed on 2951997276160 wanted 60209 found 60174
parent transid verify failed on 2951997341696 wanted 60209 found 60196
parent transid verify failed on 2951997390848 wanted 60209 found 60196
parent transid verify failed on 2952183742464 wanted 60209 found 60197
[2/7] checking extents
parent transid verify failed on 1997062340608 wanted 60209 found 60174
Ignoring transid failure
parent transid verify failed on 1997172785152 wanted 60209 found 60174
Ignoring transid failure
parent transid verify failed on 1997172785152 wanted 60209 found 60174
Ignoring transid failure
parent transid verify failed on 1997062340608 wanted 60209 found 60174
Ignoring transid failure
parent transid verify failed on 1997064454144 wanted 60209 found 60174
Ignoring transid failure
parent transid verify failed on 1997178814464 wanted 60209 found 60174
Ignoring transid failure
parent transid verify failed on 1997178814464 wanted 60209 found 60174
Ignoring transid failure
parent transid verify failed on 1997178814464 wanted 60209 found 60174
Ignoring transid failure
parent transid verify failed on 1997178814464 wanted 60209 found 60174
Ignoring transid failure
parent transid verify failed on 1997179092992 wanted 60209 found 60174
Ignoring transid failure
parent transid verify failed on 1997119029248 wanted 60209 found 60174
Ignoring transid failure
parent transid verify failed on 1997172785152 wanted 60209 found 60174
Ignoring transid failure
parent transid verify failed on 1997178814464 wanted 60209 found 60174
Ignoring transid failure
parent transid verify failed on 1997179092992 wanted 60209 found 60174
Ignoring transid failure
parent transid verify failed on 1997183156224 wanted 60209 found 60174
Ignoring transid failure
parent transid verify failed on 469008384 wanted 60209 found 60185
parent transid verify failed on 469008384 wanted 60209 found 60185
parent transid verify failed on 469008384 wanted 60209 found 60185
Ignoring transid failure
Segmentation fault

---

---

Odpovědi

[X]

parent transid verify failed on 469008384 wanted 60209 found 60185 Ignoring transid failure Segmentation fault

Detail by nebyl?

disk je OK!

A paměť s kabeláží taky?

[a1bert]

wanted 60209 found 60173

radic/disk keca o zapsanych datech, mam tu jedno PC co se chova stejne pri vypadku napajeni:

H81A BIOSTAR + WDC WD40EFRX-68N32N0

00:1f.2 SATA controller: Intel Corporation 8 Series/C220 Series Chipset Family 6-port SATA Controller 1 [AHCI mode] (rev 05)

[Mladý komsomolec]

Ano bol vypadok napajania... RAM OK (dokonca je ECC, kable urcite v poriadku). Kaslem na to, zacal som obnovu 6TB dat zo vcerajska... BTRFS nevydrzi obycajny vypadok napatia pri chybnej UPS ??? To je otras !!! Som maximalne nasraty a znechuteny. Dal som tam EXT4 opat... a pomaly obnovujem...

[Andrej]

Až ti vypadne napájení na ext4 a vyrobí ti chyby na disku, tak se to ani nedozvíš a budeš happy.

[Mladý komsomolec]

Neide o to že sa to nedozviem, ale nebude tam Segmentation fault pri checkdisku!!!

[LarryL]

Kdyby to místo "Segmentation fault" vypsalo dalších 1000 řádků "parent transid verify failed on xxxxxxx wanted 60209 found 60185" tak čemu by to pomohlo?

[fedorac]

Uplne bezva argument, `Segmentation fault` je nejspise podle mistnich obhajcu BTRFS ta spravna cesta (misto vypsani dalsich 1000 chyb - twl i kdyby jich byl milion tak se to prece nemuze stat, ale co ja vim :D ).

Sleduju tema z povzdali uz nekolik let, za me je BTRFS nejaka polofunkcni sragora, vubec nechapu ty nadsene vykriky - teda pokud adoranty neplati IBM / RedHat.

Zatim jsem akorat narazil na problem, ze se k btrfs particii nedostanu z almalinux9 a kompilovat kernel nebo dalsi nesmysly se mi teda nechtelo...

Nicmene proc to nezkusit, i bcache jsem kdysi davno zkousel, jeste to byl projekt mimo kernel s nejakym silenym autorem.

Planuju na starych rotacnich discich WD (asi jsou tam 4 - 10 TB) udelat 2 particie po par TB, kazdou na jinem disku a na ne dat neco jako btrfs raid1.

System musim aktualizovat, ale predpokladam fedora 41 (fc42 release ma byt za mesic).

Prosim tedy mistni forum o radu, jak to udelat co nejlepe, kam se podivat, na co dat pozor. Neni to snad raketova veda, s ext 4 je to par radku s `mdadm` a `mkfs` a funguje to desitky let bez zavahani (jasne, nemam cksumy). Nevyznam se v btrfs, tak budu vdecny za nasmerovani a opravy. S vysledky se rad podelim.

[PetebLazar]

Pozn. Pokud se nepletu tak skrze LV a dm-integrity je možné zajistit checksumy dat i při využití Ext4(či libovolného FS). Jestli jsem to pochopil správně pokud dojde k disproporci dat a jejich checksumů (např. SDC) vrátí (dm-integrity) vrstva té vyšší (RAID) chybu bloku a ta se zachová stejně jako v případě ReadError(tj. k rekonstrukci využije dat z ostatních nechybujících memberů RAIDu). Žádnou osobní zkušenost s tím nemám, takže prosím nechápat jako doporučení. https://docs.redhat.com/fr/documentation/red_hat_enterprise_linux/9/html/configuring_and_managing_logical_volumes/creating-a-raid-lv-with-dm-integrity_configuring-raid-logical-volumes#creating-a-raid-lv-with-dm-integrity_configuring-raid-logical-volumes

https://btrfs.readthedocs.io/en/latest/Introduction.html

[LarryL]

Uplne bezva argument, `Segmentation fault` je nejspise podle mistnich obhajcu BTRFS ta spravna cesta (misto vypsani dalsich 1000 chyb - twl i kdyby jich byl milion tak se to prece nemuze stat, ale co ja vim

Segmentation fault nebyla hláška filesystému BTRFS, který by se následně zhroutil. Byla to jen hláška obslužné utility na kontrolu chyb. Na kontrolu checksumů používám btrfs scrub. Nikdy jsem nepotřeboval btrfsck, což je zastaralý alias k btrfs check.

Nicmene proc to nezkusit, i bcache jsem kdysi davno zkousel

Bcache nehodlám zkoušet. Z EXT4 jsem přešel na BTRFS a jsem spokojen. Ani v kombinaci LUKS+BTRFS jsem nikdy nenarazil na problém a to ani při výpadku napájení.

Prosim tedy mistni forum o radu

Postupuj podle článků o BTRFS, kterých je na netu hafo + se podívej na zálohování pomocí btrfs send | receive. Je to velmi pohodlné zálohování.

[fedorac]

Dekuji za snahu o pomoc, asi to musim upresnit.

Nepotrebuji odkaz na manual, na netu hledat umim taky, nechce se mi prohrabavat celou dokumentaci, fakt ne, ptam se na zkusenosti.

Je mi jedno, co zrovna vygenerovalo segfault, opravdu ani nechci zkoumat, ktere nastroje je potreba pouzit, a ktere ne, `mkfs`, `fsck`, `mdadm` funguji desitky let bez zavahani. Ale dekuji za koment - upresnim nize.

Bcache byl jen priklad, ze jsem se nebal exprimentu v dobe, kdy to byl opravdu jen experiment mimo mainline.

Clanky na netu opravdu nehledam, zajimaji me zkusenosti. Ani zalohovani ne, jasne jsem napsal, co chci vyzkouset, takze bych spise uvital komentare k tomu co pisu prosim.

Zatim to na me pusobi tak, ze ani projekt btrfs, ani lide okolo jeste nedospeli do stadia pouzitelnosti. Takze upresneni (v podstate pro AI, ale komenty si rad prectu):

Planuju vyzkouset BTRFS na starych rotacnich discich WD (asi jsou tam 4 - 10 TB) udelat 2 particie po par TB, kazdou na jinem disku a na ne dat neco jako btrfs raid1. System musim aktualizovat, ale predpokladam fedora 41 (fc42 release ma byt za mesic). Prosim tedy mistni forum o radu, jak to udelat co nejlepe, kam se podivat (nikoliv kompletni dokumentaci, zajimaji me zkusenosti, spise si prectu negativni, nechci reklamu), na co dat pozor, a ktere nastroje jsou podminkou bezproblemoveho pouziti btrfs - a ktere urcite nepouzivat. Neni to snad raketova veda, s ext 4 je to par radku s `mdadm` a `mkfs` a funguje to desitky let bez zavahani (jasne, nemam cksumy). Mozna jeste pokud je potreba nejake specielni nastaveni filesystemu pri formatu nebo mountu nebo na co si dat pozor. Starsi poznamky k ext4: ``` D1=/dev/sda P1=4 D2=/dev/sdc P2=4

fdisk -l $D1 fdisk -l $D2

R1=/dev/md0 ll $R1 # can not exist yet

echo "create raid '$R1' from '$D1$P1' and '$D2$P2'" mdadm --create $R1 --level=1 --raid-devices=2 $D1$P1 $D2$P2 cat /proc/mdstat

## https://raid.wiki.kernel.org/index.php/RAID_setup ## asi ne ? mdadm --detail --scan >> /etc/mdadm/mdadm.conf mkfs.ext4 -m 0 $R1 # create filesystem, 0% reserverd for root mkdir /raid1 mount $R1 /raid1 df -H ```

Neco podobneho chci vytvorit s pouzitim BTRFS. Nevyznam se v btrfs, tak budu vdecny za nasmerovani a opravy. S vysledky se rad podelim.

[Stevo]

Nechápu, co chceš řešit. Nejdřív napíšeš, že si myslíš, že je to shit a pak chceš radit.

Normálně vytvoříš systém, namontuješ ho a začneš používat. Jediná věc, co se výrazně doporučuje, je montovat s volbou noatime.

Jinak to můžeš používat jako jiné filesystémy. A pokud hodláš využít možnosti, které to má navíc, budeš si muset tu dokumentaci postupně přečíst.

[LarryL]

Jestli chceš:

- poradit jak správně vytvořit na dvou discích s BTRFS v RAID1 dvě partišny a,

- získat zkušenosti takového zapojení,

tak by bylo lepší založit nový dotaz.

[PetebLazar]

Co udělá BTRFS když zjistí, že blok na jednom z memberů je nečitelný(porušený .. SDC), chápu správně že v rámci dostupné redundace (ve smyslu RAID1/RAID5/6) poskytne OS správná data, ale co udělá s postiženým místem (přenese data jinam, kde budou zase čitelná na všech zúčastěných memberech? Ptám se proto, protože již Novel Netware 3.x před 30ti lety (možná již dříve) měl vyhrazenu HotFix Area, jež umožňovala realokaci bloků v čitelné (opět redundatní podobě). O vnitřnostech BTRFS nevím zhola nic, takže dotaz do pléna zda tento filesystém disponuje na své úrovni obdobným mechanismem (real-time, během scrubu)? https://www.novell.com/documentation/nw6p/?page=/documentation/nw6p/sdiskenu/data/hi4exu95.html

[LarryL]

Jestli správně chápu dotaz, tak se ptáš co BTRFS udělá s vadnými daty u kterých nesedí checksum (před tím než je smaže a nahradí správnými daty ze zrcadleného RAID disku). Nevím o tom, že by BTRFS uchovával vadná data. Napadá mně, že taková vadná data by mohla být užitečná v nějaké laboratoři kde výrobce HDD bude debugovat jak jeho disk ničí data, ale nenapadá mě na co by vadná data potřeboval uživatel.

[PetebLazar]

Ptám se zda BTRFS provede automaticky(manuálně) kroky, které zajistí opět cílový stav optimální redundace (využitím zdravé storage) místo stávajícího degradovaného stavu (osud místně chybných dat memberu mne nezajímá). Je to již pochopitelné?

[Aleš Kapica]

Nevím, protože nemám potřebu to zkoumat. Ale domnívám se, na základě dřívějších pokusů, že nic takového automaticky nedělá. K činu přistoupí až když po těch datech něco sáhne, aby si je přečetlo. Proto by se měl v pravidelném cyklu spouštět scrub, který to zkontroluje.

..místo stávajícího degradovaného stavu

Nevím co tím chceš říct. Btrfs musíš k mountu v degradovaném stavu donutit. Za normální situace by mělo mít vždy kam uhnout, ale na to musíš myslet ty a dostatečně včas. Tak aby nedošlo k situaci že po výpadku některého z disků dojde místo – pak přijde na řadu ten degradovaný režim, kterým vypneš tu replikaci. Bez toho ti mount nedovolí, pokud ho neošálíš kupř. tím, že mu podstrčíš virtuální disk v RAM.

A řekl bych, že hodně lidí používajících Btrfs ani nenapadne, že pokud disky a datové bloky nevybalancují tak se jim automaticky bloky uložené v dobách kdy ten FS používali ještě v single-mode, samy nezkonvertují.

Zkrátka žádná AI, která by takové věci řešila automaticky, světu nevládne a vládnout nebude. Navzdory vlhkým snům krátkozrakých „vizionářů”.

[PetebLazar]

Z Vaší reakce to beru tak, že jste nepochopil můj příspěvek.

[Aleš Kapica]

Ber to jak chceš. Odpověděl jsem, a podle mně jsi to nepochopil ty, ale komunikační problém může být samozřejmě na obou stranách.

Tenhle vizionář už narazil, ale tohoto to teprv čeká.

[PetebLazar]

Bezpochyby, míra srozumitelnosti příspěvku musí být v průniku se schopností konkrétního čtenáře ho pochopit.

Abych toho riziko minely minimalizoval, dal jsem tam záměrně odkaz na ten Novell FS, který vzniklé stavy a řešení step-by-step popisuje.

Jde o čistě deterministické chování na základě pár možných stavů/pravidel, takže moc nechápu význam AI pro tento problém.

Spojitost s vizionářstvím mi již uniká zcela, při odkazování na funkcionalitu storage/FS co tu již před dekádami dlouhodobě byla (jde kdyžtak o pohled do minulosti místo do budoucnosti).

Pro ty ostatní co pochopení nevzdali, opakuji jde o za provozu vzniklou místní (member) přetrvávající nedostupnost dat. Konkrétně o real-time transparent recovery (k tomu dochází v rámci dostupné redundance) a následný relocation dat do jiného zdravého prostoru storage, což znižuje rizika vyplývající z dlouhodobé funkčnosti nad omezenou (např. chybný sektor na jednom z členů RAID6), či dokonce nulovou (chybný sektor na jednom z členů RAID1) redundancí.

[LarryL]

zda BTRFS provede automaticky(manuálně) kroky, které zajistí opět cílový stav optimální redundace

To dělá maunuálně btrfs scrub, který když zjistí, že data jsou poškozena (nesouhlasí checksum), tak je nahradí nepoškozenými daty (souhlasí u nich checksum) z jiného RAID disku.

Automaticky by k samoopravě mělo dojít když filesystém při čtení narazí na data u kterých nesouhlasí checksum.

Nefunguje to u adresářů, které jsou nastaveny jako NOCOW, tudíž nemají ani checksum.

Výše uvedené se týká poškozených dat když nesouhlasí checksum. Netýká se poškozené struktury samotného filesystému:

1) btrfs scrub kontroluje checksumy dat,

2) btrfs check kontroluje strukturu filesystemu.

Úvodní tazatel dostával chyby při btrfs check (alias btrfsck), tak těžko říct jestli mu vadný HW rozbil jen data, které by mohl opravit zkopírováním dat ze zálohy nebo zda mu nějak rozbil i strukturu filesystému.

[PetebLazar]

Ty chyby mohou být zjednodušeně dvojího druhu buď nečitelný blok (již IO CRC error), nebo podezření na SDC (blok je z hlediska IO čitelný, ale jeho vypočtený checksum nesedí s ve FS uloženým).

Kde se v případě první chyby uloží zrekonstruovaná data, aktuálnímu úmístění nelze již s hlediska uchování dat věřit vzniklo např. místně poškozeným povrchech plotny HDD?

Při vzniku takové chyby v rámci vnitřní logiky HDD (TLER/ERC/CCTL) patrně dojde k realokaci (přeadresaci) logického sektoru do rezervní oblasti HDD (na zcela jiný fyzický sektor). To je patrně z pohledu FS neviditelná operace, takže s jejím výsledkem asi nemůže jakkoli počítat. Možná, že BTRFS počítá s tím, že k tomuto došlo a uloží zrekonstruovaná data opakovaně do logicky identického místa (logický sektor z hlediska adresace LBA již odkazuje na zcela jiný doufejme funkční sektor).

[LarryL]

Kde se v případě první chyby uloží zrekonstruovaná data, aktuálnímu úmístění nelze již s hlediska uchování dat věřit vzniklo např. místně poškozeným povrchech plotny HDD?

Nemyslím si, že se BTRFS bude snažit zapisovat do fyzicky stejného bloku na HDD. Vzhledem k tomu, že BTRFS je copy-on-write by to nedávalo smysl. Zapíše na jiné místo na disku podobně jako při editaci souboru, tzn. adresa fyzického bloku se starými daty se z filesystému vyřadí a bude se tvářit jako volné místo.

[PetebLazar]

Ta chyba nastane při čtecí operaci, copy-on-write je snad procesem evokovaným aplikací/OS vyžádanou změnou souboru na FS?

https://surajsinghbisht054.medium.com/understand-btrfs-file-system-copy-on-write-sub-volumes-snapshots-quota-group-part-1-c6305f87df9b

Z dohledaného to vypadá, že BTRFS "don't keep track of bad sectors", takže to asi bude jak říkáte a v budoucnu (po uplynutí retence?) použije stejné místo pro jiná data.

Pokud ovšem na úrovni HDD dojde v mezidobí k realokaci sektoru do rezerved zone není to asi problém jelikož ten původní logický sektor XYZ bude po tomto zásahu HDD ukazovat na zcela jiný fyzický sektor (zatím nevyužívaný/zdravý?).

Pokud by tyto rezervní sektory HDD došly zapíší se nová data přes původní nespolehlivé místo.

Při příštím scrubu BRTFS patrně zapíše data z jeho pohledu poškozená data správně (vypadá to, že na stejné pozici "it can only repair filesystem damage by copying from other known good replicas" a dokumentace CoW při scrubu explicitně nezmiňuje).

[pet I.]

My tady těch výpadků napájení jednu dobu měli opravdu nechutně moc a všechny BTRFS to přežívaly bez problémů. Až mě to udivovalo.

Tohle vypadá jako HW co při výpadku napájení ničí obsah disku.

[Aleš Kapica]

A dobře mu tak.

Mně se taky kámoš dušoval jak ty jeho super disky nejsou skvělé a bezchybné, když jsem testoval Btrfs v raid6 módu a řvalo. Třetina jich byla zralá do koše, protože vracely špatné checksumy. Nevěřil, nevyhodil, použil jinde a do půl roku byly tak jako tak všechny v koši.

[Lenny]

Mozno zalezi aj od verzie jadra a ake distro, neni linux ako linux. Podla mna zalezi od verzie jadra to je dost podstatna vec.

[a1bert]

a co mas za disk, taky WD?

https://lore.kernel.org/linux-btrfs/20190624052718.GD11831@hungrycats.org/t/

Now let's look for some bad stuff. How about a list of drives that were involved in parent transid verify failure events occurring within 1-10 power cycles after mkfs events:

Model Family: Western Digital Green Device Model: WDC WD20EZRX-00DC0B0 Firmware Version: 80.00A80

Change the query to 1-30 power cycles, and we get another model with the same firmware version string:

Model Family: Western Digital Red Device Model: WDC WD40EFRX-68WT0N0 Firmware Version: 80.00A80

Removing the upper bound on power cycle count doesn't find any more.

The drives running 80.00A80 are all in fairly similar condition: no errors in SMART, the drive was apparently healthy at the time of failure (no unusual speed variations, no unexpected drive resets, or any of the other things that happen to these drives as they age and fail, but that are not reported as official errors on the models without TLER). There are multiple transid-verify failures logged in multiple very different host systems (e.g. Intel 1U server in a data center, AMD desktop in an office, hardware ages a few years apart). This is a consistent and repeatable behavior that does not correlate to any other attribute.

Now, if you've been reading this far, you might wonder why the previous two ranges were lower-bounded at 1 power cycle, and the reason is because I have another firmware in the data set with _zero_ power cycles between mkfs and failure:

Model Family: Western Digital Caviar Black Device Model: WDC WD1002FAEX-00Z3A0 Firmware Version: 05.01D05

These drives have 0 power fail events between mkfs and "parent transid verify failed" events, i.e. it's not necessary to have a power failure at all for these drives to unrecoverably corrupt btrfs. In all cases the

[Mladý komsomolec]

Ano, WD... To si robia srandu? Ako som to mal pred nasadením na WD disky vedieť?

[LarryL]

Shrnutí celé „logiky“ v duchu tohoto dotazu:

• „Já mám svůj disk rád. Určitě je bezchybný! Tak ho nekritizujte! Btrfs ho kritizuje, proto musí být chyba v Btrfs!“
• „Proč mi Btrfs tvrdí, že mám problém? Já nemám problém! Já nechci vědět, že ztrácím data! Nezjištěná ztráta dat přece není problém! Problém, o kterém nevím, nemám!“
• „To neumí Btrfs ztrácet data potichu? Podívejte — Ext4 i XFS mi ta data poztrácí potichu a nebude mě tím obtěžovat!“
• „Nechci vědět, že mi mizí data, stejně jako bych nechtěl vědět, že mi hoří dům. Když o problému nevím, problém neexistuje!“
• Co je při velkém problému s diskem lepší — dozvědět se o něm brzy, nebo potichu dostat náhodně pozměněná data také do záloh?
• „Do záloh! Jasně! Já chci, aby mi můj nespolehlivý disk kontaminoval moje data a pak i moje zálohy! A především o tom NECHCI VĚDĚT!“

To je fakt z prdele logika, tohleto. Jako přes kopírák u každého trollingu ohledně Btrfs, už 15 nebo kolik let, stále totéž.

Ani za těch ± 20 let, od dob, kdy se začaly objevovat první filesystémy hodné 21. století, s vestavěnými checksumy, snapshoty, copy-on-write a redundancí, někteří jedinci stále nepochopili, která b(l)ije.

Filesystémy opravdu (ale opravdu) nemohou za špatné disky, které nedodržují zápisové bariéry a nechovají se podle specifikací, aby pak v benchmarku měly 5% navrch.

[pavele]

Shrnutí celé „logiky“ v duchu tohoto dotazu:

• „Já mám svůj disk rád. Určitě je bezchybný! Tak ho nekritizujte! Btrfs ho kritizuje, proto musí být chyba v Btrfs!“
• „Proč mi Btrfs tvrdí, že mám problém? Já nemám problém! Já nechci vědět, že ztrácím data! Nezjištěná ztráta dat přece není problém! Problém, o kterém nevím, nemám!“
• „To neumí Btrfs ztrácet data potichu? Podívejte — Ext4 i XFS mi ta data poztrácí potichu a nebude mě tím obtěžovat!“
• „Nechci vědět, že mi mizí data, stejně jako bych nechtěl vědět, že mi hoří dům. Když o problému nevím, problém neexistuje!“
• Co je při velkém problému s diskem lepší — dozvědět se o něm brzy, nebo potichu dostat náhodně pozměněná data také do záloh?
• „Do záloh! Jasně! Já chci, aby mi můj nespolehlivý disk kontaminoval moje data a pak i moje zálohy! A především o tom NECHCI VĚDĚT!“

To je fakt z prdele logika, tohleto. Jako přes kopírák u každého trollingu ohledně Btrfs, už 15 nebo kolik let, stále totéž.

Ani za těch ± 20 let, od dob, kdy se začaly objevovat první filesystémy hodné 21. století, s vestavěnými checksumy, snapshoty, copy-on-write a redundancí, někteří jedinci stále nepochopili, která b(l)ije.

Filesystémy opravdu (ale opravdu) nemohou za špatné disky, které nedodržují zápisové bariéry a nechovají se podle specifikací, aby pak v benchmarku měly 5% navrch.

¨ Vzhledem k tvým dlouhodobým zkušenostem s btrfs bys tu mohl uvést, jaké harddisky jsou vhodné pro tento filesystém a kterým se raději vyhnout.

[Peter Golis]

¨ Vzhledem k tvým dlouhodobým zkušenostem s btrfs bys tu mohl uvést, jaké harddisky jsou vhodné pro tento filesystém a kterým se raději vyhnout.

Tak načo čakáš, daj zoznam.

[Pepan35]

Ta to by mě také opravdu zajímalo které disky se pro BTRFS hodí a které ne viz diskuze. Přece si nekupuji disk podle BTRFS. Naopak zvolím spolehlivý FS. Pokud mě nějaký FS několikrát zboří desktop přestanu ho používat a zvolím jiný FS! Samoshřejmě po otestování kvality disku. Nepotřebuji hodný nespolehlivý "FS 21 století". Stačí mi prověřený a spolehlivý, který mě nezklame.

[xxl]

Jak můžeš poznat, který disk nebo souborový systém je na něco vhodný, když ani nečteš logy?

[Aleš Kapica]

Takové seznamy jsou úplně na kokot, protože osvědčené disky fungují tak dlouho, že už se nevyrábí.

Už dlouho jsem na vadný disk nenarazil, ale problémový disk se při použití s Btrfs obvykle projevil velice brzy, takže ho bylo možné vrátit bez udání důvodu v rámci 14 denní lhůty. A ty co přežily těch 14 dní fungují všechny dodnes.

[Peter Golis]

Dopr, pokazil si to. On mal zoznať nejaký zoznam hardware ktorý si mohol akurát tak z prsta vycucať. Alebo z podobného odvisnutého prívesku.

[pavele]

Dopr, pokazil si to. On mal zoznať nejaký zoznam hardware ktorý si mohol akurát tak z prsta vycucať. Alebo z podobného odvisnutého prívesku.

[fedorac]

kdyz tak jestli muzu poprosit o koment nebo tip. dekuji

pripevek vyse #61

[PetebLazar]

Myslím, že v těch počtech HDD co se v běžných řešeních využívají a rychlost s jakou se modelově(technologicky) obměňují asi nemá smysl po těch dokonalých pátrat. Snažší je možná stanovit jakým modelům se zdaleka vyhnout (tichá vzpomínka na IBM HDD z Hungary).

Například HDD z lůna Hitachi (Ultrastar řada) bude asi považována za ty povedenější a pak člověk pod tímto označením narazí na tohle.

https://www.alza.cz/wd-ultrastar-12tb-d5477452.htm?o=4

https://www.alza.cz/western-digital-18tb-ultrastar-dc-hc550-sata-d6285718.htm?o=5

https://www.alza.cz/wd-ultrastar-dc-hc330-10tb-wus721010ale6l4-d6831512.htm

[Pepan35]

Nemáš pravdu. Ty problémy se vyskytují zcela nahodile. Někdy po výpadku elektiky, jindy zcela náhodně nejhoší je že nejčastěji PC je do vypnutí OK a zcela nahodile nenaběhne že některý subvolume je porušen. To by se člověk modlil před zapnutím PC aby naběhl. Koupil jsem tři ssd disky M2 Samsung,WDblack s chladičem a Kingstona. Všechny stejný problém a systém zcela nahodile nenaběhl. Všechny disky důkladně otestována a naprosto bez chyb. Použil jsem tedy XFS a za celo dobu absolutně žádný problém. Podle Andreje stejně hnijou pomalu data

[Peter Golis]

To je typické chovanie keď sa nezapíše cache do trvalej oblasti na disk. Jadro rozumného OS to robí jak periodicky, tak aj pri vynútení správcom alebo službou na to určenou. A to hlavne pri vypínaní. Dáta sa nestihnú zapísať.

Naozaj chceš tvrdiť že XFS netrpí takouto chybou ak má od tretej generácie iba checksum metadát, a checksum dát stále (podľa wiki) chýba a ty si to tak nemáš ako všimnúť až do doby kým ti aplikácia nevyhlási chybu?

[Pepan35]

Opravdu se mi s XFS ani jednou nevyskytl problém. A zkoušel jsem to na uvedených ssd. Podle tebe tedy BTRFS nestihne zapsat data? Ext4 jsem kdysi dávno používal na Samsungu evo tam taky se nikdy nestalo že systém nenaběhl. XFS je taky cow a opravdu je to bez problémů. Proto již nechci btrfs používat to je celé. Opravdu bych chtěl zkusit někdy bcachefs jak se bude chovat. Třeba ten bude jako xfs i u mě stabilní.

[Peter Golis]

Podle tebe tedy BTRFS nestihne zapsat data?

To som nikdy netvrdil. A tvrdím pravý opak: Jadro pri vypínaní čaká na potvrdenie zapísania na disk. Ak disk potvrdí že zápis prebehol, tak jadro vypne napájanie. A ak disk klame o vykonanom zápise, tak prídeš o dáta chybou HW.

Opravdu se mi s XFS ani jednou nevyskytl problém.

Ak sa smiem opýtať: Akým spôsobom bola vykonaná kontrola konzistencie dát, len tým že či systém nabehne (keď do systémovej oblasti sa zapisuje len zriedka) alebo zbehne fsck ktorý nemá ako skontrolovať konzistenciu dát keďže XFS nerieši konzistenciu dát?

Proto již nechci btrfs používat to je celé.

Tak ho už nepoužívaj, a nesnaž sa tvoj názor násilím vnucovať ostatným.

Ja napríklad nechcem chodiť do kostola, a tak doň jednoducho nechodím. A nenájdeš ma skandovať pred kostolom s transparentami odpudzujúcimi chodenie do kostola. Ale ty to v prípade BTRFS s takými transparentami preháňaš, a vybľakuješ ako malé dieťa ktoré si rozbilo hračku a zvaľuje vinu na prd vo vetre.

[Pepan35]

Nemá cenu pokračovat! Když systém nenaběhl řešil jsem hlavně jak co nejrychleji pokračovat v práci. Skoro vždy byl problám s subvolume.

Píšu že btrfs nepoužívám a používat nikdy nebudu tak mi to nemusíš připomínat. Svůj názor NIKOMU nevnucuji a svůj názor na btrfs jsem napsal abych přidal svoji zkušenost s tímto FS. To že se ti to nelíbí a máš třeba opačnou zkušenost ti nikdo nebere. Já svůj problém vyřešil a jsem spokojený.

[Peter Golis]

Keby si tvoj názor nevnucoval, tak tu nevybľakuješ ako sopliak ktorému fotrovci zakázali ísť s partiou na víkendovú chatu. Alebo ako keby ťa partia na tú chatu odmietla zobrať, a rovno ti to do tváre povedali lebo ťa majú v mobiloch blokovaného. No a to bude asi dôvod prečo sa snažíš prejavovať aspoň ako náhodný anonym, čo je stále veľmi obľúbené u zatrpknutých ašpirantov na dôverníkov.

[Pepan35]

No když tě baví urážet nic s tim nenadělám. Jenom jsi mě utvrdil v názoru na některé občany...

[Peter Golis]

Takže keď ti niekto vysvetlí kde si urobil a akú chybu, a aj ti detailne vysvetlí že sa chováš nevhodne, tak je to pre teba urážka.

Tak to máš teda dosť zaujímavý problém. A smajlík ti to nevyrieši.

[Pepan35]

Hele chytrolíne čti co včera o spolehlivosti napsal např. zexelon uživatel zexelon

[Aleš Kapica]

Dalo ti to hodně práce, najít příspěvek stejného hlupáka? Možná by ses měl obtěžovat přečtením toho co mu na to napsali.

[Pepan35]

Nevím že bych reagoval na tebe. Baví tě prudit?

[Want]

A tebe?

[redneck]

Vyřeší ty trable aktualizace FW? Mám WD Red Plus WD40EFPX a například podle Synology by pro tenhle disk a jejich NAS DS124(BTRFS) měl stačit FW 81.00A81.

[pavele]

Vyřeší ty trable aktualizace FW? Mám WD Red Plus WD40EFPX a například podle Synology by pro tenhle disk a jejich NAS DS124(BTRFS) měl stačit FW 81.00A81.

Zkus napsat výrobci o tvých problémech s FS a jestli už to v té aktualizaci vyřešili.

Odpověď postni sem.

Určitě by to pomohlo i vývojářům btrfs a jiným uživatelům - třeba se zvýší kvlalita disků WD.

[Peter Golis]

Čo robí NextGen FS ma /dev/mapper, ak sa smiem opýtať?

[Mladý komsomolec]

btrfs nad cryptsetupom...

[Peter Golis]

Ale veď enkrypciu v BTRFS vyvíjajú už približne od roku 2008, ak ma pamäť neklame.

[Max]

Myslím, že ne, že jen v todo listu. Ale o ten vývoj se nezajímám, čerpám jen z webu, možná na tom někdo dělá...
Zdar Max

[Peter Golis]

Nuž, jeden z dôvodov prečo som použil iný NextGEN FS. Síce tam nemám možnosť zmeniť typ RAID, ale to zatiaľ nepotrebujem.

[Max]

Šifruji celé blokové zařízení pomocí luks, takže pro mně to opravdu není nějaký problém a nevidím ani důvod, proč by to pro někoho mohla být překážka.
Zdar Max

[Peter Golis]

Je to o jednu vrstvu viac. A NextGEN FS zvyknú nahrádzať kopec kadejakých vrstiev akými sú napríklad deduplikačná vrstva, kryptovacia vrstva, vrstva redundancie a podobne.

Ale to je na dlhú diskusiu a život je na také niečo moc krátky.

[dustin]

Chápu, že HW problém disku filesystém nevratně poničí, ale pokud zkolabuje jeho obslužná utilita na přístup do paměti, pak je takový FS dost nedůvěryhodný. Vlastně se člověk ani nemá šanci dozvědět víc, když utilita umře během práce.

[pavele]

Možná by se v todo měl uvádět seznam použitelných disků. když je podle výše uvedeného odkazu problém i s WD black, který jsem vždy považoval za slušný disk do serveru.

[Pepan35]

https://www.abclinuxu.cz/poradna/linux/show/484984

https://www.abclinuxu.cz/poradna/unix/show/495014

Ano BTRFS je hodně nebezpečný FS! Nikdy vice bych ho nepoužil. Přešel jsem na XFS a od té doby jsem neměl jedivý problém i při výpadcích el. sitě a to UPS nepoužívám. Ještě v budoucnu zkusím Bcachefs. BTRFS již nikdy více!

[Aleš Kapica]

Udělal jsi mi tím ohromnou radost, věříš tomu?

[LarryL]

https://www.abclinuxu.cz/poradna/linux/show/484984

Tazatel ani jednou nereagoval v diskuzi. Vypadá to na trolling.

https://www.abclinuxu.cz/poradna/unix/show/495014

Neposlal jsi výpis z dmesg nebo journalctl, ani jsi nespustil scrub jak ti v diskuzi radili. Jediná tvoje informace byla, že ti to napsalo Failed subvol=/@home. Musíš uznat, že to je dost málo na rozpoznání v čem je problém. Dovodit z takové hlášky, že je vadné BTRFS je dost bláznivé.

[Pepan35]

Zkusil jsem sudo mount -o subvol=@home /dev/sda /home odpovědí bylo že neexistuje

sudo btrfs subvolume list /mnt také subvol=@home nenašel.

Problém byl že po zapnutí PC naprosto náhodně chyběl home-subvolume. Jinak btrfs fs byl ok. Jako lama jsem tedy použil cow fs XFS a problém tak pro sebe vyřešil. To je celé.

[LarryL]

Jinak btrfs fs byl ok

V tom případě nebyl problém v BTRFS, ten by se nedokázal zotavit kdyby se mu vnitřní chybou ztratila celá subvolume. Co máš za distro, abych si na něj dal pozor?

No já bych spíš tipoval chybu mezi klávesnicí a židlí.

[LarryL]

Taky bych to tak viděl.

[Pepan35]

Stávalo se mi to s Manjaro a CachyOS

[LarryL]

Obě vychází z Archu, ale že by ti náhodně smazaly subvolumu... a navíc pokaždé tu samou... to se mi nezdá. To je pravděpodobnější, že subvolumu smazal nějaký tvůj script, cron... Příště musíš více pátrat v journalctl, abys věděl cos vlastně vyvedl.

[Pepan35]

Děkuji za odpověď. Jednou jsem se mi podařilo otevřít journalctl, ale tam bylo takových záznamů že jsem jako bfu nic nepochopil. Že by subvolume smazal nějaký můj scriprt, nebo cron se mi nezdá, protože se mi to několikrát stalo velmi brzy po přeinstalování os, kdy jsem obnovil pouze data. Je možné že si nějak nesedl btrfs s mým hw a to bych jako bfu nedokázal odstranit. Nikdy nebyl problém pokud os naběhl. Stalo se to nahodile pouze po zapnutí PC system nenaběhl s tím že chybí home subvolume.

[LarryL]

kdy jsem obnovil pouze data

Mohl jsi tím obnovit script nebo conf, který pak spustila jiná aplikace a smazala home. Je to pravděpodobnější vysvětlení než chyba v BTRFS.

Je možné že si nějak nesedl btrfs s mým hw

To není možné. Pokud je vadný HW, tak BTRFS hlásí chyby jako v úvodním příspěvku této diskuze. Celý BTRFS by se pak měl přepnout do read-only. Ty ale popisuješ situaci kdy někdo nebo něco naprosto čistě a bez chyb smazalo subvolumu @home.

Stalo se to nahodile pouze po zapnutí PC system nenaběhl s tím že chybí home subvolume.

O to snadnější by mělo být hledání v žurnálu. Hledal bys v journalctl těsně před vypnutím a po zapnutí.

[xxl]

V té odkazované diskusi jsi posílal výpis /proc/mounts, kde byl @home uveden. Takže je zřejmé, že někde nepíšeš pravdu. A jestli v tom máš takový hokej, je vysoce pravděpodobné, že popisované chování není chybou btrfs.

[PetebLazar]

I když bude filesystem správně navržen a implementován správná funkčnost (zajišťění konzistence FS) bude záviset na tom zda HDD/SSD opravdu udělají to co mu slíbili, že udělají. Mám tím na mysli především režim write-back kdy storage/řadič potvrdí OS(FS) provedení zápisové operace ještě dříve než k ní opravdu fyzicky dojde. Pokud se tak dodatečně nestane, navzdory transakční povaze FS může dojít k jeho nekonzistenci. To co mělo zabránit nekozistenci FS nebylo fyzicky provedeno. V případě multi-device řešení je tu navíc riziko odlišné úspěšnosti propsání "dirty blocks" v případě výpadku. Write-thru režim určitě stojí nějaký výkon, ale výhodou je asi definovatelnéjší chování storage z pohledu procesu FS.

[Max]

Co vím, tak běžné ssd/nvme disky nezaručují, že by uživatel při výpadku proudu nepřišel o data. Tj. consumer sféra ještě nedávno neměla moc dobře implementováno Power Loss Protection. Někteří i v consumer sféře používají tantalové polymerové kondenzátory, které by měly zajistit dostatek proudu k tomu, aby se dokončil zápis. Nicméně těžko říci, jak to mají jednotlivé vendoři iplementováno jak na hw úrovni, tak na sw úrovni (firmware).
Kdo má tedy ntb a je zvyklý natvrdo vypínat ntb, tak mu btrfs nejspíše začne hlásit nějaké problémy (v režimu warning a asi jen při checku, běžně asi vůbec), ale bude dál fungovat. Tož má zkušenost.
Zdar Max

[PetebLazar]

Data, o který si filesystém nemyslí, že se zapsala a ve skutečnosti nikoli by neměla být pro na transakcích postaveném FS problém. Jde o to, že při write-back policy se potvrdí ukončení operace (diskem řadiči/řadičem OSu) ješte předtím než se ty fyzicky provedou (což může rozbít konzistenci transakce).

Myslím, že některé řadiče (DELL PERC?) mají nastavení, které policy u HDD vynutí (write-thru/write-back), předpokládám, že k tomu používají wcache/wcache-sct příkazy SMARTu. https://man.freebsd.org/cgi/man.cgi?smartctl(8)

[Max]

Problém je, že řadič o tomto případě moc nerozhoduje, to je věc hw a firmware toho disku. Jakmile disk bude hlásit zápis, i když není proveden a nebude dostatečně implementováno PLP, tak bude v případě výpadku proudu k nekonzitenci docházet. Minimalizovat riziko lze jen redundancí a pravidelnými scruby.
Zdar Max

[PetebLazar]

Myslím, že při write-thru policy HDD nebude operace zápisu z pohledu OS ukončená dokud tomu tak skutečně nebude (úroveň PLP je irelevantní). Stejné platí i pro řadič, který může mít write-thru policy na své úrovni (write-back policy nedoporučováno bez cache zálohujícího akumulátoru). https://www.dell.com/support/manuals/en-us/poweredge-vrtx/sperc8-8e-ug-pub/physical-disk-write-cache-policy?guid=guid-a561d9bb-64d3-4c7a-b72f-e8b3ac1d226a&lang=en-us

[Max]

Já tomu rozumím, ale také vím, jaký humáč za fw mají v sobě různé consumer disky. Jinými slovy, nespoléhal bych na to.
Zdar Max

[PetebLazar]

Zkusím večer pomocí fio ověřit zda ta volba wcache má vůbec nějaký dopad (snížení iops) u comsumer HDD.

Tady jsou čísla co lze asi očekávat.

https://www.percona.com/blog/fsync-performance-storage-devices/ Popravdě moc nechápu použití comsumer HDD v multi-device storage, je cenový rozdíl vůči enteprise modelům dnes natolik významný? 16TB

[Max]

Používám consumer jen u sebe v PC, kde jedu multidevice. Systém+home mám na 2x 1TB NVMe (btrfs RAID1) a další data pak na 3x 8TB btrfs RAID1.
Zdar Max

[lertimir]

Ale i u sebe přecházim na Enterprise disky, konkrétně od Toshiby (z Mironetu). Mám hodně blízké tomu, co píšeš: 2x1TB NVMe luks btrfs RAID1 na system a home a nyní 5 ruzných disků od 3 do 8TB na zbylá data v brtfs RAiD1. Výměna za Toshiba Enterprise Capacity MG09 18TB 512e nebo Toshiba N300 NAS 18TB plánována na léto. Ostatně nevíte, jaký je mezi nimi rozdíl?

[PetebLazar]

NAS HDD je Advanced Format, záruku 24 měsíců, má ERC, do 8-bay solutions

https://www.toshiba-storage.com/products/toshiba-internal-hard-drives-n300/

Enterprise HDD podporuje 512e, podpora RAID (bez ERC?), záruka 60 měsíců, zmiňuji persistent write cache, limit 500TB/Y

https://www.toshiba-storage.com/products/enterprise-capacity-hard-drive-mg-series/

[PetebLazar]

Statistika je neúprosná, dnešní enterprise HDD deklarují 1 mil hod MTBF, teoretická hodnota jež se údajně získá tak že se po uplynutí doby záběhu nechá 1000 přeživších HDD dále běžet a pokud se jeden z nich za 1000 hodin porouchá získá se zmíněná hodnota.

Pokud se podíváme na statistiky Blaze, tyto měly roční poruchovost 4372 hdd, při natočených 101,906,290 hdd_dní (tj. 2,4 mld hdd_hod) podělením těchto hodnot se dostaneme na 559 000 hod/hdd. To je sice méně než zmíněný 1 000 000, ale to patrně půjde na vrub starších hdd, které jsou již za dobou předpokládané živostnosti. Křivka poruchovosti má typicky tvar průřezu miskou (na začátku v záběhu a ke konci předpokládané životnosti je porouchost typicky větší), hodnota MTBF se vztahuje na chod u "dna misky". https://www.backblaze.com/cloud-storage/resources/hard-drive-test-data