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

[lertimir]

Ultrastary jsou považoval za lepší, ale když je WD Red Pro a Gold je v 18TB dražší než Ulrastár 20 tak nevím. Ale Toshiba se mi zdá pořád ok.

[PetebLazar]

"... jsou považoval ..."

Ano, to to asi přesně vystihuje.

[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

[[Jooky]]

Cize si to zhrnme ... Na pristrojovke v aute sa rozsvieti cervene "check engine". Namiesto riesenia problemu treba vymontovat "check engine" ziarovku, lebo ved motor nastartoval, tak musi byt v poriadku !!!!!

Ze disk cez SMART povie, ze je v poriadku, este neznamena, ze aj naozaj je ... Mam tu teraz u seba WD Red, ktory ma vsetky SMART data v poriadku. Short / Long test ukaze dobre a dokonca aj badblocks ... lenze tomu disku niekolko sektorov odchadza postupne. Ked do toho disku priamo cez /dev/sdX zapisem nejake data (cize bez FS, cisto raw device), tak hodinu-dve tie data ide vycitat. Ked ich skusim precitat za 10-24 hodin, tak niekolko sektorov to vrati s pozmenenymi datami ... proste nejake sektory odhnivaju a FW disku je to uplne jedno. Na tie sektory po precitani vrati stale nieco ine ... ked na tom bol btrfs, tak scrub strasnym sposobom nadaval a ma pravdu, ten disk je kaput ... ked by som na ten disk dal ext4 a tie sektory netrafia metadata, tak to pojde ... ale po case najdem poskodene subory, ktore kludne uz mohli prejst do zaloh.

Ludia majte uz rozum. Ked raz btrfs povie, ze je nejaky problem, tak treba hladat kde v HW je problem ... nie klapky na oci a tvrdi, ze FS ktory si spokojne necha odhnit data (ext4), nic nehlasil ... ext4 ked nema poskodene metadata, tak vrati co mu prislo z disku. Ci su to zapisane data, je uz otazka ...

Pri SOHO diskoch sa vobec neda spolahnut na SMART a tiez, ze disk hodi I/O error, ked doslo k pozmeneniu dat na disku. Nielen spominany WD, ale aj dalsie znacky bez problemov pri citani poskodenych sektorov vratia nahodne data ... a ked toto padne do nejakej kritickej struktury btrfs, tak proste bude hlasit vela errorov.

fyi: Na mojom laptope mam btrfs, ktory som vyrabal 10 rokov dozadu. Ked som mal problem s GPU driverom, tak sa mi laptop aj niekolko krat za den zasekol. Do toho som ho nespocetny raz omylom vytiahol z elektriky (nemam baterku) a crashol kernel pri roznych testoch ... btrfs mi tu normalne funguje a kazdy krat to prezilo (scrub ok, tak isto porovnanie s datami v backupe). Btrfs vobec nie je tak citlivy FS ako sa to tu par ludi snazi prezentovat ... Mozno na zamyslenie stoji aj to, ze Btrfs uz zacina byt ako default nielen v Linux distribuciach, ale napr aj NAS ako Synology (tam mam Btrfs od 2016 a tiez funguje dobre)

[Peter Golis]

Sú ľudia ktorí si vážia svoje dôležité dáta, a sú ľudia ktorí nechcú byť informovaní o chybách pretože im nevadí ich nekonzistencia.

[pavele]

Btrfs je prostě nejlepší, bez chyb, používám ho přes třicet let bez problémů a stejně jako systemd ho budu nutit naprosto všem, protože je nutné ho používat všude bez vyjímky a pokud někomu zkolabuje, může si za to sám.

[Peter Golis]

Ak trp93 nutkavou obsesiou, tak do toho. Ale skús to robiť podobne ako jehovisti, bez agresie.

[PetebLazar]

Tipnul bych si, že to byl ze strany paveleho sarkasmus.

Pro ty co ho nejsou schopni rozpoznat jsou tu pomocné skupiny jako například Sarcasmaholics Anonymous.

[Peter Golis]

V dnešnej dobe sa už nepoužíva zastaralý a nemoderný názov nutkavá obsesia, ale používa sa názov obsedantno-kompulzívna choroba.

Najmä ak sa jedná o pokus o veľmi prehľadný trolling zo známeho zoznamu tém. Na to sa ozaj najšťavnatejšie reaguje evanjelizáciou vyznávačov tradičných a zastaralých produktov a vyhovorením sa na vtip.

[PetebLazar]

V changelogu verze 6.7 BTRFS je zmíněn "raid-stripe-tree", tak snad se během druhé dekády stabilních verzí tohoto FS dočkáme funkčního RAID5(6) bez rizika "write-hole".

https://btrfs.readthedocs.io/en/latest/Feature-by-version.html

[Peter Golis]

Bežný užívateľ alebo SOHO segment nepoužíva diskový shelf, takže mu stačí mirror na redundantný zápis. Veľké firmy a korporácie čo používajú diskové shelfy alebo diskové polia ktorých veľkosť sa ráta v plne naložených rackoch majú iné priority ako handrkovať sa o takýchto žabomyších vojinách. Diskové pole je sporebák podliehajúci plánovanej obmene aj kvôli spotrebe elektriky.

[PetebLazar]

RedHat BTRFS podle odkazu níže zcela vykopl z RHELu.

https://access.redhat.com/solutions/197643

Holt ten, kdo s ohledem na spolehlivost dnešních HDD touží po větší redundanci se musí poohlédnout jinde.

[Peter Golis]

Že RH vyradil niečo z portfólia je vedľajšie. Podobne vyradilo HP napríklad Jabber, a ten stále žije a zdokonaluje sa.

[Max]

Co si vzpomínám, tak ho jeden čas používali, ale probíhalo tam tolik změna a překotný vývoj, že se nakonec rozhodli vylepšovat XFS, nad kterým pak postavili Stratis.
Za tu dobu XFS dost vyrostlo, přibylo tam spoustu fcí atd.
Takto se RedHat rozhodl někdy v roce 2017, možná dříve.
Zdar Max

[GeorgeWH]

aha, takze medzi SOHO a big enterprise nic ine neexistuje, lebo ty si povedal? boze ty si kokot...

[Peter Golis]

Cenovo existuje, kvalitatívne neexistuje. Ty si pre zmenu slušne vychovaný mladý muž atletickej postavy ktorý je obľúbený v kolektíve, a susedia ťa vždy s radosťou pozdravia.

[Pepan35]

"Na pristrojovke v aute sa rozsvieti cervene "check engine" A je to falšný poplach a příčinou je neodladěný BTRFS

"Ze disk cez SMART povie, ze je v poriadku, este neznamena, ze aj naozaj je " To se nezlob ale milionkrát raději věřím SMARTu než nesmyslům vycházejících z BTRFS. Po přechodu na jiný FS jsem nikdy žádný problém nezaznamenal a nikdy o žádná data nepřišel! Btw podle tebe koupím nový disk a nebudu věřit SMARTu že je nový a bezchybný dokud na něj nepustím BTRFS? To nevymyslíš

Zrovna ty jsi ten pravej, kterej je předurčenej k hodnocení odladěnosti btrfs. Zrovna ty...

Jak jsi zjistil, že jsi nepřišel o žádná data na souborovém systému, kterej nemá kontrolní součty, by mě teda fakt zajímalo.

[Pepan35]

Uvažuju selským rozumem BTRFS mi nekolikrát poničil data a PC nenaběhl. Zvolil jsem jiný fs a hodně dlouhou dobu je vše bez problémů. Narozdíl od tebe nejsem btrfsfil a použil jsem pro mě bezproblémový fs. To je vše.

Zapomněl jsi napsat, že máš vysokou školu života...

Btrfs ti žádný data neponičil. Akorát tě upozorňoval na to, že tvůj hardware je na hovno. Ale ty, protože jsi pako, sis ani nepřečet, co ti píše do logu. Zato místo toho od tý doby tapetuješ diskuse svejma blábolama.

[Pepan35]

Pro tebe jsou to bláboly pro mě zkušenost. Požádal bych tě tedy o radu jak mimo BTRFS zjistím že je můj hardware na hovno? Doufám že nabídneš mimo BTRFS jinou možnost jeho otestování hw který by tvoje tvrzení podpořil. Já žádný nenašel a vždy vše naproso bez chyb. Pokud neporadíš tak ty o tom víš kulový hovno a jenom se zviditelňuješ

[Peter Golis]

Ak samotný HW zatajuje chyby a tebou preferovaný FS nerobí kontrolu konzistencie dát, tak máš jedinú možnosť overiť si či si časom neprišiel o dáta. Musíš si ten kontrolný súčet vytvoriť sám pred zápisom dát, uchovať ho a v pravidelných intervaloch porovnávať či ti sedí kontrolný súčet súboru.

My ostatní máme túto úlohu delegovanú na FS ktorý rieši kontrolu konzistencie jednotlivých blokov. A rieši to či už pri pravidelnom scrube (obdoba scandisk/chkdrk/fsck), alebo pri čítaní daných dát.

Low cost segment zatajuje silent data corruption už vyše 10 rokov, tiež mi nejaké fragmenty poškodilo. U mňa na to doplatila časť zbierky legálne nadobudnutých multimédií, takže škoda bola skoro žiadna. Jednoducho som tie DVD vytiahol zo šuflíka, a grabol znova.

[Aleš Kapica]

Nejsi tak trochu masochista? Jinak si nedovedu vysvětlit s jakou úporností zde opakovaně demonstruješ vlastní hloupost. Nám je úplně putna jakým způsobem si otestuješ svůj HW. A stejně tak je nám jedno co se stane s tvými daty. Tvoje hloupost, tvoje ztráty. Rčení: „Komu není rady, tomu není pomoci.” Jsi už nejspíš někdy slyšel. Tak se nad ním zkus taky zamyslet.

[Pepan35]

Je ti hovno po tom jestli jsem nebo nejsem masochista. Píšeš kraviny místo rady čím tedy otestovat můj "vadný" hw abych veděl jak se vyvarovat případné ztráty dat.

[Aleš Kapica]

Tobě žádné rady není. Sorry.

Ty ses nějak zasek. Jesli chceš vědět, že máš data v cajku, musíš mít jak je kontrolovat. Na to ti o kousek vejš kolega radil kontrolní součty. Když ti přestanou sedět, máš tutově po datech. Když nemáš kontrolní součty, víš kulový o tom, v jakým stavu data sou. A ty součty a jejich kontrolu dělá btrfs jaksi automaticky. Akorát je potřeba semotamo číst logy. Jo a btrfs se jen tak samoodsebe nerozsype.

[Pepan35]

To je furt dokola! Kontrolní součty jsou ok. Nahodile po vypnutí pc znovu nenaběhne. Pokaždé zmizí home-subvolume. Děje se to zcela nahodile. Co mám potom kontrolovat? Co si pomohu když musím systém obnovit a čekat znovu až nenaběhne. Prostě použitím jiného fs se to neděje a data jsou ok. O nic nejde mám zálohy, ale naštve když potřebuji něco dělat a místo toho dělat obnovu. Popsal jsem svůj problém a pro mě řešení. Nejsem zvědavý na Kapicovi a Golisovi urážky. Když se Golis narodil byl jsem druhým rokem na vojně. Co mi má co kecat o "fotrovcích" a o kostelech smrad jeden! Ano jsem běžnej uživatel-samouk, který již není nejmladší a zdaleka ne tak bystrý jako kdo je z oboru. Proč urážky? ať tedy Golis na mě nereaguje když nechce.

[Max]

Viz kauzy se Samsungem, WD apod. Nemusí se projevit všude, záleží na použitém čipsetu, verzi kernelu apod. Taktéž se nemusí dít kontinuálně, ale opravdu z pohledu uživatele náhodně. A vše to jsou věci, kdy se data ničí na pozadí, aniž by o tom referoval firmware disku, řadič atd.
Jinak by mně zajímalo, jak víš, že jsi nepřišel o data? Pokud požíváš fs, který si konzistenci nehlídá (checksummy dat, metadat apod.), tak jak víš, že jsi nepřišel o data? Máš u všech důležitých dat vygenerován checksum do souboru (třeba pomocí sha1sum) a zpětně porovnáváš?
Zdar Max

[Pepan35]

Tak kontrolní součty u důležitých dat na pc a na záložních discích občas (nepravidelně) kontroluji a vše je ok.

[xxl]

Jestliže si ručně děláš kontrolní součty a potom je také kontroluješ, tak nejsi BFU, ale pokročilý uživatel. Takže, podle mě, je v tvých silách přečíst si v případě potřeby dokumentaci nebo dohledat něco na internetu. V tomto případě samozřejmě ve vztahu k btrfs.

Nehledal jsi náhodou pomoc též na Redditu?

https://www.reddit.com/r/archlinux/comments/13kegei/cant_mount_btrfs_subvolume_with_home_but_i_can/

Tazatel tam používal timeshift a dostal se do stejných problémů, jako ty.

Tam to tedy vypadalo, že chyba nebyla v btrfs.

[Pepan35]

Díky, ale za pokročilého uživatele se opravdu nepovažuji. Timeshift jsem nikdy nepoužíval.

[[Jooky]]

"Ze disk cez SMART povie, ze je v poriadku, este neznamena, ze aj naozaj je " To se nezlob ale milionkrát raději věřím SMARTu než nesmyslům vycházejících z BTRFS. Po přechodu na jiný FS jsem nikdy žádný problém nezaznamenal a nikdy o žádná data nepřišel! Btw podle tebe koupím nový disk a nebudu věřit SMARTu že je nový a bezchybný dokud na něj nepustím BTRFS? To nevymyslíš

O servre sa staram cez 25 rokov a zacinal som v dobach, kedy boli len IDE / PATA disky ... za tu dobu mozem konstatovat:

- niekolko diskov nam prestalo aktualizovat SMART udaje. Proste zastavil sa pocet hodin, ktore reportovali. Nemenili sa udaje ako teplota / pocet zapisanych udajov a podobne.

- niekolko diskov nam prestalo pustat short / long testy. Proste disk sa rozhodol, ze prikaz na smart test odignoruje. Smartctl vratil, ze test pustil, ale ked som pozeral neskorsie log, tak tam nebol zapisany vysledok. Podla statusu ani test nepustil.

- WD disky su famozne v tom, ze napr v pripade problemu inkrementuju pocet realokovanych sektorov, ale nemaju problem ten pocet aj znizovat. Cize napr vyradim disk z raidu, lebo ma vadne sektory. Zapisem nanho nuly a zrazu sa SMART tvari, ze je vsetko v poriadku.

- vela vyrobcov a to vratane WD, Seagate, Hitachi nema problem vratit pozmenene data a nevyhodit pri tom I/O error ... vacsina RAID 1 HW / SW implementacii ocakava, ze ak je problem s diskom, tak hodi I/O error a data sa precitaju z druhej kopie. Co ale spravi ak nevyhodi error ? ... dostane sa to az do aplikacie.

- za celu dobu, co sa staram o servre / pocitace, som nevidel jeden disk, ktory by si nastavil chybovy SMART overal status a nabadal na vymenu ... sem tam neprejde smart short / long, sem tam to ukaze pending sektor, ale furt to pise, ze disk je 100% v poriadku ... takze tak

Takze na zaklade coho tomu mam verit ? Tie disky, ktore prestali aktualizovat data, alebo pustat testy zacali aj vyhadzovat I/O chyby, alebo pocas restartu PC umreli ... tiez nam niekolko diskov umrelo len tak. Proste kernel napisal, ze bol odpojeny a ked som restartol server, tak ho bios uz nenasiel.

Este v dobe, ked maximum co sa dalo bol ext3, som mal system, co mi staticku cast servrov kontroloval cez kontrolne sucty ... som si 100% isty, ze zmeny ktore to zachytilo isli z disku. Napr v kombinacii dva disky + md raid + ext3 som niekolko krat videl situaciu, ked kontrola systemu nasla zmenu. Po odstraneni (manualny fail) jedneho disku z md raidu sa zrazu problematicke subory "opravili" ... co znamena, ze disk posielal nezmysel a skrz toho, ze citanie je RR to raz hodilo spravny obsah a raz chybne data ... samotny disk pritom ukazal smart long test v poriadku a az po prepise disku novymi datami ukazal realokovane sektory (neunuval sa spravne nastavit pending pri tych necitatelnych) ... no toto je presne problem, ktory riesi BTRFS. Tam su kontrolne sucty na vsetko a tym padom sa pri kazdom citani overi, ci data su naozaj spravne, alebo disk poslal nejake smetie ...

[Pepan35]

Děkuji to jsem opravdu nevěděl a SMART za nemylný pokládal. Vidím že budu muset svůj názor přehodnotit. U mě je nějaká hw anomálie s BTRFS, ale až pořídím nový hw tak určitě znovu btrfs zkusím.

[Max]

Spíš je to tak, že SMART dřív vůbec nefungoval a nejlepším ukazatelem, zda je disk ok, byl badblocks v destruktivním režimu, jelikož v nedestruktivním neodhalil všechny chyby. Postupem času se SMART stával spolehlivějším, ale nikoli bezchybným. S narůstající kapacitou, příchodem SSD a různými optimalizacemi s přeskládáváním dat (firmware si ukládá data podle svého algoritmu) se objevil nový problém, kdy už nelze používat ani badblocks a jediné, na co se člověk může spolehnout, je SMART (který není dokonalý a různí vendoři různě interpertují různé honnoty, a to i napříč svými produkty), případně chyby, co odhalí kernel (CRC, způsobené vadným kabelem, nějakým rušením, nebo co já vím), nebo chyby, co odhalí kontrolní součty dat a metadat, které dělá FS (což je asi nejlepší ukazatel).
Třeba ZFS má krásný přehled toho, zda nějaký disk chyboval při čtení, při zápisu apod., a z toho pak lze vyvodit nějaké důsledky.
Zdar Max

[Aleš Kapica]

Sepsáno jasně, polopaticky a zbytečně. Pepan35 uvažuje selským rozumem a data mu ničí Btrfs.

Že na něj reagují uživatelé, co ten FS dlouhé roky používají a ví že HW se nikdy nedá 100% věřit ho vůbec nezajímá.

OT. Používal jsem v Btrfs raid1 kdysi tři darované, údajně jen mírně jeté 120GB SSD disky. Pokud byly zapojené pouze dva, bylo to rychlé, jenže nestačila kapacita. Když ale byly zapojeny všechny tři, vše se brutálně zpomalilo, včetně X serveru. Smart se přitom tvářil úplně normálně a v logu žádné chyby nebyly. Zkoušel jsem to různě přehazovat, přes různé porty. Všechno jedno. Nakonec jsem se naštval, ty darované disky hodil do koše, koupil 2x Samsung EVO 860 a od té doby už byl klid. A taky nekupuji levný, byť nový hw – a už nikdy se nevyskyl žádný z problémů s jakými na mne dřív obraceli šetřílci, co si na ně zadělali svými výhodnými koupěmi.

[Pepan35]

Ano pán je opět nachytro. Napsal jsem to jako BFU že nekolikrát mi zmizel home subvolome po zapnutí PC. Možná jsem to měl formulovat jinak, aby byl pán spokojen. Posledně jsem napsal že jsem věřil pouze SMARTu a v budoucnu to budu muset na základě vysvětlení Jooky a Maxe přehodnotit. Co chceš více? Btw naprosto stejný problém se dvěma ssd Samsung jeden starší 860EVO a nový 870EVO a poslední wd black sn850x heatsing. Všude to dopadlo naprosto stejně a home subvolume zmizel. Taky nekupuju žádný šubruňk. Jestli chceš abych odvolal že je pro mě BTRFS naprosto nepoužitený na tomhle hw tak máš smůlu.

Potřebuji PC na práci a ne pořád něco opravovat a studovat logy. Opakuji mám to vyřešeno k plné spokojenosti. Zálohuju a konrolní součty sedí. Když si někdy pořídím nový mb s jiným cpu tak to znovu vyzkouším. Třeba BTRFS není vhodný na moje železo i když to diskem v žádném případě není.

[Want]

Mně je úplně fuk co si pytlíkuješ na svém železe. A na tvém odvolání houby záleží. Každý svého štěstí strůjcem. A dobrých 62% ho potřebuje vrchovatě, jak aktuálně vypovídá anketa.

[pavele]

A teď si představ, že majorita lidí ve světě používá Windows s NTFS.

[Want]

Jo, jo. Zrovna včera jeden zástupce majority přišel o data velice pěkným způsobem.

Přišel za námi s tím, že má problém s diskem. NVME 1TB ani ne dva roky staré. Když jsme najeli diskless, byl vidět. Jenže to mělo háček - Bitlocker.

No. Tak strávil několik chvil prohledáváním všech možných i nemožných účtů, aby získal klíč. Jenže když už to vypadalo, že ho má - nic. To pole bylo prostě prázdné.

Kolega pak zjistil - na jiném notebooku, když preventivně ten Bitlocker vypínal, aby to s ním nedopadlo stejně, že se ten klíč neukládá do toho účtu hned. A pokud se něco stane s TPM, je fuč. Takže v případě prvním jsou data nenávratně ztraceny.

[Want]

A kolik vás je. Takových.. Co ho mají pro jistotu vytištěný na papíře?

[Max]

Ve firemním světě je klíč zálohován do AD. V personálním světě je klíč zálohován do cloudu (pokud má člověk přihlášen účet ve win).
Problém je, že uživatelé většinou ani nevědí, že šifrují, protože si třeba koupí notebook, kde je bitlocker aktivní od vendora a pak se může lehce stát, že se mázne TPM, či se něco změní a bude to chtít od uživatele recovery key, který nebude znát.
Zdar Max

[Aleš Kapica]

Ve firemním světě je klíč zálohován do AD. V personálním světě je klíč zálohován do cloudu (pokud má člověk přihlášen účet ve win).

No. To jsme si do včerejška mysleli taky. Jenže k tomu dojde až po zadoménování. Jinak je to jak píšeš, ale háček je v tom, že ten systém uživatele neupozorní na to, že používá šifrovaný diskový oddíl který nemá vyexportovaný klíč. Ta možnost uložení, nebo vytištění klíče se totiž nabídla, teprve když si dal kolega zobrazit vlastnosti disku, aby ten bitlocker vypnul.

Podle mne by měl systém na tuhle skutečnost uživatele viditelně upozornit, aby nežil v domnění, že už není potřeba nic řešit.

[xxl]

Už jsi věnoval psaní příspěvků o tom, jak ti zmizel home subvolume, spoustu času. Kdybys tolik času věnoval přečtení chyb v logu, jejich vygůglení, přečtení dokumentace k btrfs, mohl jsi to mít dávno sám vyřešené i s btrfs.

A kdybys už na začátku napsal do diskuse, jak to máš přesně nastavené a co se píše v tom logu, někdo by ti býval mohl poradit. To jsi ale neudělal a tak ti nikdo poradit nemohl.

[Peter Golis]

Vybrať si triedneho nepriateľa a obviniť ho z vlastnej chyby je vždy jednoduchšie. Historici potvrdia nespočetnými a doloženými príkladmi.

[Pepan35]

Ty by jsi se měl léčit a naučit číst kreténe

[PetebLazar]

Takže doporučujete využít vlastní náboženské přesvědčení a podle něj ostatní obvinit z jejich chyb?

[Peter Golis]

Pri výbere vždy odporúčam zvážiť potreby ktoré má akákoľvek služba, produkt alebo tovar splniť. A na otázky "čo je najlepšie" nereagujem, ak nepoznám potreby pýtajúceho sa. Takí ľudia aj tak zoberú to čo je najlacnejšie, a potom hádžu vinu za svoj výber na druhých.

[Max]

Samsung 860EVO a 870EVO jsou pro Linux to nejhorší. Roky zabugovaný fw, který v Linuxu způsoboval ztrátu dat. Záleží na chipsetu a dalších věcech. Ty dva disky jsou ukázkou totálního odpadu a nezájmu Samsungu řešit Linux svět. Na Linuxu nikdy neprovozovat, protože buď budeš mít štěstí a jen přijdeš o pár fcí těch disků, nebo budeš mít smůlu a budeš přicházet o data.
Pokud jde o to WD, tak víme, co na něj vyplavalo.
Takže ne, díky, zůstávám u Crucialu.
Zdar Max

[Pepan35]

ten M.2 Crucial 1TB s chladičem jsem před časem zkoušel. Byl starší a ok, ale hodně oproti uvedeným topil.

[Max]

Tady chinook měl Samsung SSD 990 PRO 4TB a pořád problémy (SMART a vše okolo nepoukazovalo na problémy, vše zářivě čisté). Vyměnil za Crucial T700 a od té doby žádný problém.
A mám u sebe další odkazy na různé dotazy s problémy, kde měli autoři jeden společný ukazatel, Samsung SSD.
Zdar Max

[chinook]

Mám ten disk na windows, sice ne systémovej, ale je používanej a žádný problém. Tzn. bude to jak si říkal. Kombinace BTRFS a linuxu.

Jinak EVO 860 a 870 mám na linuxu v několika desítkách instalací na EXT4 a taky žádný problém. A to už x let.

Jinak na ten problémový stroj kde byl problém SSD 990 PRO 4TB po výměně za ten crucial T700 doted běží bez problémů a je tam celkem vysoké zatížení. A je tam stále BTRFS.

[Aleš Kapica]

Mám ten disk na windows, sice ne systémovej, ale je používanej a žádný problém. Tzn. bude to jak si říkal. Kombinace BTRFS a linuxu.

Jinak EVO 860 a 870 mám na linuxu v několika desítkách instalací na EXT4 a taky žádný problém. A to už x let.

Asi ne, když se nikde jinde než v linuxu nepoužívá.

[pavele]

Takže btrfs nepoužívat na discích WD a Samsung?

[Max]

O tom jsem ale psal, že můžeš mít štěstí, protože ztráta dat u 860 a 870 byla v nějaké kombinaci s chipsetem / řadičem (Samsung 860 EVO NCQ Issue with AMD SATA Controller), jenomže to nebyl jediný problém těch disků (Samsung 860/870 SSDs Continue Causing Problems For Linux Users) atd.
A celou dobu je to o nějakém druhu nekompatibility v Linuxu. Proto jsem psal, že Samsung v Linuxu ne, protože buď unstable, nebo ztráta dat, nebo člověk oželí nějaké fci (viz ty blacklisty v kernelu) a bude pomalejší. Ve Windows jsou lidi spokojený, takže tam bych nic neřešil.
A nejhorší je, že různé zprávy se objevují v řadě, nejde jen o jednu serii, nebo model.
Člověk tedy riskuje nákupem potencionální problém, který ale nemusí nastat.
Jestli v kombinaci s btrfs nastává nějaký problém častěji, to netuším.
Zdar Max

[Pepan35]

Určitě máš mnohem větší zkušenosti, ale já dlouhou dobu používal Samsung sata 860 a 870 a asi rok a půl WD black 850x heatsing nvme s ext4 a nikdy se žádný problém neobjevil a žádná data jsem nemusel obnovovat. Nemůže to být třeba tím že se docela rychle vylepšuje kernel a tím některé problémy postupně mizí?

[Max]

Myslím, že jsem to napsal jasně a poslal jsem zdroje, kde je jaký problém a jak dlouho se ty problémy řešily, za jakých podmínek ty problémy byly atd. Poznámku "neměl jsem problém" moc nechápu, obzvláště v kontextu, že jsi problémy měl (viz tvé dotazy zde na abc).
Pokud se točíš na tom, že jsi problémy neměl jen s ext4 a vinu vidíš v btrfs, tak na tuto víru už taktéž nemám co říci, padlo zde vše, nemá smysl se opakovat.
Zdar Max

[LarryL]

Zrovna tady mám WD Blue na kterém je ext4. Už kdysi ztratil data. Na to jsem přišel náhodou když jsem otevřel poškozený soubor (následoval pád a zápis chyby do S.M.A.R.T). Samotný filesystém ext4 si nikdy na nic nestěžoval. Kdybych se nestrefil do poškozeného souboru, dodnes bych si myslel, že data jsou OK.

Kernel mám nový. Možná tě čeká podobné prozření když používáš FS bez checksumů.

Malá ukázka jak stav toho disku vypadá když jsem na něj teď spustil badblocks (test stále jede):

badblocks -wsv -t 0x00 /dev/sda
Hledají se špatné bloky v režimu čtení i zápis
Od bloku 0 do 1953514583
Zkouším se vzorkem 0x00: hotovo                                               
Čtení a porovnání: 491168 % hotovo, 4:36:43 uplynulo. (0/0/0 chyb)
491169 % hotovo, 4:36:46 uplynulo. (1/0/0 chyb)
491170 % hotovo, 4:36:50 uplynulo. (2/0/0 chyb)
491171 % hotovo, 4:36:53 uplynulo. (3/0/0 chyb)
492876 % hotovo, 4:37:04 uplynulo. (4/0/0 chyb)
492877 % hotovo, 4:37:08 uplynulo. (5/0/0 chyb)
492878 % hotovo, 4:37:11 uplynulo. (6/0/0 chyb)
492879 % hotovo, 4:37:15 uplynulo. (7/0/0 chyb)
499908 % hotovo, 4:37:29 uplynulo. (8/0/0 chyb)
499909 % hotovo, 4:37:32 uplynulo. (9/0/0 chyb)
499910 % hotovo, 4:37:36 uplynulo. (10/0/0 chyb)
499911 % hotovo, 4:37:39 uplynulo. (11/0/0 chyb)
501612 % hotovo, 4:37:50 uplynulo. (12/0/0 chyb)
501613 % hotovo, 4:37:54 uplynulo. (13/0/0 chyb)
501614 % hotovo, 4:37:57 uplynulo. (14/0/0 chyb)
501615 % hotovo, 4:38:01 uplynulo. (15/0/0 chyb)
503320 % hotovo, 4:38:11 uplynulo. (16/0/0 chyb)
503321 % hotovo, 4:38:15 uplynulo. (17/0/0 chyb)
503322 % hotovo, 4:38:18 uplynulo. (18/0/0 chyb)
503323 % hotovo, 4:38:22 uplynulo. (19/0/0 chyb)
505024 % hotovo, 4:38:33 uplynulo. (20/0/0 chyb)
505025 % hotovo, 4:38:36 uplynulo. (21/0/0 chyb)
505026 % hotovo, 4:38:40 uplynulo. (22/0/0 chyb)
505027 % hotovo, 4:38:43 uplynulo. (23/0/0 chyb)
506736 % hotovo, 4:38:54 uplynulo. (24/0/0 chyb)
506737 % hotovo, 4:38:57 uplynulo. (25/0/0 chyb)
506738 % hotovo, 4:39:01 uplynulo. (26/0/0 chyb)
506739 % hotovo, 4:39:04 uplynulo. (27/0/0 chyb)
508440 % hotovo, 4:39:15 uplynulo. (28/0/0 chyb)
508441 % hotovo, 4:39:19 uplynulo. (29/0/0 chyb)
508442 % hotovo, 4:39:22 uplynulo. (30/0/0 chyb)
508443 % hotovo, 4:39:26 uplynulo. (31/0/0 chyb)
510148 % hotovo, 4:39:36 uplynulo. (32/0/0 chyb)
510149 % hotovo, 4:39:40 uplynulo. (33/0/0 chyb)
510150 % hotovo, 4:39:44 uplynulo. (34/0/0 chyb)
510151 % hotovo, 4:39:47 uplynulo. (35/0/0 chyb)
511852 % hotovo, 4:39:58 uplynulo. (36/0/0 chyb)
511853 % hotovo, 4:40:01 uplynulo. (37/0/0 chyb)
511854 % hotovo, 4:40:05 uplynulo. (38/0/0 chyb)
511855 % hotovo, 4:40:08 uplynulo. (39/0/0 chyb)
515472 % hotovo, 4:40:19 uplynulo. (40/0/0 chyb)
515473 % hotovo, 4:40:23 uplynulo. (41/0/0 chyb)
515474 % hotovo, 4:40:26 uplynulo. (42/0/0 chyb)
515475 % hotovo, 4:40:30 uplynulo. (43/0/0 chyb)
517180 % hotovo, 4:40:40 uplynulo. (44/0/0 chyb)
517181 % hotovo, 4:40:44 uplynulo. (45/0/0 chyb)
517182 % hotovo, 4:40:47 uplynulo. (46/0/0 chyb)
517183 % hotovo, 4:40:51 uplynulo. (47/0/0 chyb)
518884 % hotovo, 4:40:58 uplynulo. (48/0/0 chyb)
518885 % hotovo, 4:41:02 uplynulo. (49/0/0 chyb)
518886 % hotovo, 4:41:05 uplynulo. (50/0/0 chyb)
518887 % hotovo, 4:41:09 uplynulo. (51/0/0 chyb)
520592 % hotovo, 4:41:16 uplynulo. (52/0/0 chyb)
520593 % hotovo, 4:41:19 uplynulo. (53/0/0 chyb)
520594 % hotovo, 4:41:23 uplynulo. (54/0/0 chyb)
520595 % hotovo, 4:41:26 uplynulo. (55/0/0 chyb)
522296 % hotovo, 4:41:34 uplynulo. (56/0/0 chyb)
522297 % hotovo, 4:41:37 uplynulo. (57/0/0 chyb)
522298 % hotovo, 4:41:41 uplynulo. (58/0/0 chyb)
522299 % hotovo, 4:41:44 uplynulo. (59/0/0 chyb)
524008 % hotovo, 4:41:51 uplynulo. (60/0/0 chyb)
524009 % hotovo, 4:41:55 uplynulo. (61/0/0 chyb)
524010 % hotovo, 4:41:58 uplynulo. (62/0/0 chyb)
524011 % hotovo, 4:42:02 uplynulo. (63/0/0 chyb)
525712 % hotovo, 4:42:10 uplynulo. (64/0/0 chyb)
525713 % hotovo, 4:42:14 uplynulo. (65/0/0 chyb)
525714 % hotovo, 4:42:17 uplynulo. (66/0/0 chyb)
525715 % hotovo, 4:42:21 uplynulo. (67/0/0 chyb)
527420 % hotovo, 4:42:28 uplynulo. (68/0/0 chyb)
527421 % hotovo, 4:42:32 uplynulo. (69/0/0 chyb)
527422 % hotovo, 4:42:35 uplynulo. (70/0/0 chyb)
527423 % hotovo, 4:42:39 uplynulo. (71/0/0 chyb)
529124 % hotovo, 4:42:51 uplynulo. (72/0/0 chyb)
529125 % hotovo, 4:42:54 uplynulo. (73/0/0 chyb)
529126 % hotovo, 4:42:58 uplynulo. (74/0/0 chyb)
529127 % hotovo, 4:43:01 uplynulo. (75/0/0 chyb)
532744 % hotovo, 4:43:13 uplynulo. (76/0/0 chyb)
532745 % hotovo, 4:43:17 uplynulo. (77/0/0 chyb)
532746 % hotovo, 4:43:20 uplynulo. (78/0/0 chyb)
532747 % hotovo, 4:43:24 uplynulo. (79/0/0 chyb)
532748 % hotovo, 4:43:31 uplynulo. (80/0/0 chyb)
532749 % hotovo, 4:43:35 uplynulo. (81/0/0 chyb)
532750 % hotovo, 4:43:38 uplynulo. (82/0/0 chyb)
532751 % hotovo, 4:43:42 uplynulo. (83/0/0 chyb)
534448 % hotovo, 4:43:50 uplynulo. (84/0/0 chyb)
534449 % hotovo, 4:43:54 uplynulo. (85/0/0 chyb)
534450 % hotovo, 4:43:57 uplynulo. (86/0/0 chyb)
534451 % hotovo, 4:44:01 uplynulo. (87/0/0 chyb)
536156 % hotovo, 4:44:09 uplynulo. (88/0/0 chyb)
536157 % hotovo, 4:44:13 uplynulo. (89/0/0 chyb)
536158 % hotovo, 4:44:16 uplynulo. (90/0/0 chyb)
536159 % hotovo, 4:44:20 uplynulo. (91/0/0 chyb)
536160 % hotovo, 4:44:27 uplynulo. (92/0/0 chyb)
536161 % hotovo, 4:44:31 uplynulo. (93/0/0 chyb)
536162 % hotovo, 4:44:34 uplynulo. (94/0/0 chyb)
536163 % hotovo, 4:44:38 uplynulo. (95/0/0 chyb)
537864 % hotovo, 4:44:46 uplynulo. (96/0/0 chyb)
537865 % hotovo, 4:44:50 uplynulo. (97/0/0 chyb)
537866 % hotovo, 4:44:54 uplynulo. (98/0/0 chyb)
537867 % hotovo, 4:44:57 uplynulo. (99/0/0 chyb)
537868 % hotovo, 4:45:04 uplynulo. (100/0/0 chyb)
537869 % hotovo, 4:45:08 uplynulo. (101/0/0 chyb)
537870 % hotovo, 4:45:11 uplynulo. (102/0/0 chyb)
537871 % hotovo, 4:45:15 uplynulo. (103/0/0 chyb)
539568 % hotovo, 4:45:23 uplynulo. (104/0/0 chyb)
539569 % hotovo, 4:45:27 uplynulo. (105/0/0 chyb)
539570 % hotovo, 4:45:30 uplynulo. (106/0/0 chyb)
539571 % hotovo, 4:45:34 uplynulo. (107/0/0 chyb)
539572 % hotovo, 4:45:41 uplynulo. (108/0/0 chyb)
539573 % hotovo, 4:45:44 uplynulo. (109/0/0 chyb)
539574 % hotovo, 4:45:48 uplynulo. (110/0/0 chyb)
539575 % hotovo, 4:45:51 uplynulo. (111/0/0 chyb)
541276 % hotovo, 4:46:00 uplynulo. (112/0/0 chyb)
541277 % hotovo, 4:46:04 uplynulo. (113/0/0 chyb)
541278 % hotovo, 4:46:07 uplynulo. (114/0/0 chyb)
541279 % hotovo, 4:46:11 uplynulo. (115/0/0 chyb)
541280 % hotovo, 4:46:18 uplynulo. (116/0/0 chyb)
541281 % hotovo, 4:46:21 uplynulo. (117/0/0 chyb)
541282 % hotovo, 4:46:25 uplynulo. (118/0/0 chyb)
541283 % hotovo, 4:46:28 uplynulo. (119/0/0 chyb)
542984 % hotovo, 4:46:37 uplynulo. (120/0/0 chyb)
542985 % hotovo, 4:46:41 uplynulo. (121/0/0 chyb)
542986 % hotovo, 4:46:44 uplynulo. (122/0/0 chyb)
542987 % hotovo, 4:46:48 uplynulo. (123/0/0 chyb)
542988 % hotovo, 4:46:55 uplynulo. (124/0/0 chyb)
542989 % hotovo, 4:46:58 uplynulo. (125/0/0 chyb)
542990 % hotovo, 4:47:02 uplynulo. (126/0/0 chyb)
542991 % hotovo, 4:47:06 uplynulo. (127/0/0 chyb)
544696 % hotovo, 4:47:14 uplynulo. (128/0/0 chyb)
544697 % hotovo, 4:47:17 uplynulo. (129/0/0 chyb)
544698 % hotovo, 4:47:21 uplynulo. (130/0/0 chyb)
544699 % hotovo, 4:47:24 uplynulo. (131/0/0 chyb)
546400 % hotovo, 4:47:31 uplynulo. (132/0/0 chyb)
546401 % hotovo, 4:47:35 uplynulo. (133/0/0 chyb)
546402 % hotovo, 4:47:38 uplynulo. (134/0/0 chyb)
546403 % hotovo, 4:47:42 uplynulo. (135/0/0 chyb)
548108 % hotovo, 4:47:49 uplynulo. (136/0/0 chyb)
548109 % hotovo, 4:47:53 uplynulo. (137/0/0 chyb)
548110 % hotovo, 4:47:56 uplynulo. (138/0/0 chyb)
548111 % hotovo, 4:48:00 uplynulo. (139/0/0 chyb)
551724 % hotovo, 4:48:08 uplynulo. (140/0/0 chyb)
551725 % hotovo, 4:48:12 uplynulo. (141/0/0 chyb)
551726 % hotovo, 4:48:15 uplynulo. (142/0/0 chyb)
551727 % hotovo, 4:48:19 uplynulo. (143/0/0 chyb)
553432 % hotovo, 4:48:26 uplynulo. (144/0/0 chyb)
553433 % hotovo, 4:48:30 uplynulo. (145/0/0 chyb)
553434 % hotovo, 4:48:33 uplynulo. (146/0/0 chyb)
553435 % hotovo, 4:48:37 uplynulo. (147/0/0 chyb)
555140 % hotovo, 4:48:45 uplynulo. (148/0/0 chyb)
555141 % hotovo, 4:48:49 uplynulo. (149/0/0 chyb)
555142 % hotovo, 4:48:52 uplynulo. (150/0/0 chyb)
555143 % hotovo, 4:48:56 uplynulo. (151/0/0 chyb)
556844 % hotovo, 4:49:06 uplynulo. (152/0/0 chyb)
556845 % hotovo, 4:49:09 uplynulo. (153/0/0 chyb)
556846 % hotovo, 4:49:13 uplynulo. (154/0/0 chyb)
556847 % hotovo, 4:49:16 uplynulo. (155/0/0 chyb)
558552 % hotovo, 4:49:29 uplynulo. (156/0/0 chyb)
558553 % hotovo, 4:49:33 uplynulo. (157/0/0 chyb)
558554 % hotovo, 4:49:36 uplynulo. (158/0/0 chyb)
558555 % hotovo, 4:49:40 uplynulo. (159/0/0 chyb)
560260 % hotovo, 4:49:48 uplynulo. (160/0/0 chyb)
560261 % hotovo, 4:49:51 uplynulo. (161/0/0 chyb)
560262 % hotovo, 4:49:55 uplynulo. (162/0/0 chyb)
560263 % hotovo, 4:49:59 uplynulo. (163/0/0 chyb)
560624 % hotovo, 4:50:06 uplynulo. (164/0/0 chyb)
560625 % hotovo, 4:50:09 uplynulo. (165/0/0 chyb)
560626 % hotovo, 4:50:13 uplynulo. (166/0/0 chyb)
560627 % hotovo, 4:50:16 uplynulo. (167/0/0 chyb)
561964 % hotovo, 4:50:23 uplynulo. (168/0/0 chyb)
561965 % hotovo, 4:50:27 uplynulo. (169/0/0 chyb)
561966 % hotovo, 4:50:31 uplynulo. (170/0/0 chyb)
561967 % hotovo, 4:50:34 uplynulo. (171/0/0 chyb)
562328 % hotovo, 4:50:41 uplynulo. (172/0/0 chyb)
562329 % hotovo, 4:50:45 uplynulo. (173/0/0 chyb)
562330 % hotovo, 4:50:48 uplynulo. (174/0/0 chyb)
562331 % hotovo, 4:50:52 uplynulo. (175/0/0 chyb)
563672 % hotovo, 4:50:59 uplynulo. (176/0/0 chyb)
563673 % hotovo, 4:51:03 uplynulo. (177/0/0 chyb)
563674 % hotovo, 4:51:06 uplynulo. (178/0/0 chyb)
563675 % hotovo, 4:51:10 uplynulo. (179/0/0 chyb)
565380 % hotovo, 4:51:17 uplynulo. (180/0/0 chyb)
565381 % hotovo, 4:51:20 uplynulo. (181/0/0 chyb)
565382 % hotovo, 4:51:24 uplynulo. (182/0/0 chyb)
565383 % hotovo, 4:51:27 uplynulo. (183/0/0 chyb)
568996 % hotovo, 4:51:34 uplynulo. (184/0/0 chyb)
568997 % hotovo, 4:51:38 uplynulo. (185/0/0 chyb)
568998 % hotovo, 4:51:42 uplynulo. (186/0/0 chyb)
568999 % hotovo, 4:51:45 uplynulo. (187/0/0 chyb)
570704 % hotovo, 4:51:52 uplynulo. (188/0/0 chyb)
570705 % hotovo, 4:51:56 uplynulo. (189/0/0 chyb)
570706 % hotovo, 4:51:59 uplynulo. (190/0/0 chyb)
570707 % hotovo, 4:52:03 uplynulo. (191/0/0 chyb)
572408 % hotovo, 4:52:10 uplynulo. (192/0/0 chyb)
572409 % hotovo, 4:52:14 uplynulo. (193/0/0 chyb)
572410 % hotovo, 4:52:17 uplynulo. (194/0/0 chyb)
572411 % hotovo, 4:52:21 uplynulo. (195/0/0 chyb)
574116 % hotovo, 4:52:28 uplynulo. (196/0/0 chyb)
574117 % hotovo, 4:52:31 uplynulo. (197/0/0 chyb)
574118 % hotovo, 4:52:35 uplynulo. (198/0/0 chyb)
574119 % hotovo, 4:52:38 uplynulo. (199/0/0 chyb)
575824 % hotovo, 4:52:46 uplynulo. (200/0/0 chyb)
575825 % hotovo, 4:52:49 uplynulo. (201/0/0 chyb)
575826 % hotovo, 4:52:53 uplynulo. (202/0/0 chyb)
575827 % hotovo, 4:52:56 uplynulo. (203/0/0 chyb)
577532 % hotovo, 4:53:04 uplynulo. (204/0/0 chyb)
577533 % hotovo, 4:53:08 uplynulo. (205/0/0 chyb)
577534 % hotovo, 4:53:11 uplynulo. (206/0/0 chyb)
577535 % hotovo, 4:53:15 uplynulo. (207/0/0 chyb)
579236 % hotovo, 4:53:22 uplynulo. (208/0/0 chyb)
579237 % hotovo, 4:53:26 uplynulo. (209/0/0 chyb)
579238 % hotovo, 4:53:29 uplynulo. (210/0/0 chyb)
579239 % hotovo, 4:53:33 uplynulo. (211/0/0 chyb)
580944 % hotovo, 4:53:40 uplynulo. (212/0/0 chyb)
580945 % hotovo, 4:53:43 uplynulo. (213/0/0 chyb)
580946 % hotovo, 4:53:47 uplynulo. (214/0/0 chyb)
580947 % hotovo, 4:53:50 uplynulo. (215/0/0 chyb)
582652 % hotovo, 4:53:58 uplynulo. (216/0/0 chyb)
582653 % hotovo, 4:54:01 uplynulo. (217/0/0 chyb)
582654 % hotovo, 4:54:05 uplynulo. (218/0/0 chyb)
582655 % hotovo, 4:54:08 uplynulo. (219/0/0 chyb)
586268 % hotovo, 4:54:21 uplynulo. (220/0/0 chyb)
586269 % hotovo, 4:54:24 uplynulo. (221/0/0 chyb)
586270 % hotovo, 4:54:28 uplynulo. (222/0/0 chyb)
586271 % hotovo, 4:54:31 uplynulo. (223/0/0 chyb)
587976 % hotovo, 4:54:38 uplynulo. (224/0/0 chyb)
587977 % hotovo, 4:54:42 uplynulo. (225/0/0 chyb)
587978 % hotovo, 4:54:45 uplynulo. (226/0/0 chyb)
587979 % hotovo, 4:54:49 uplynulo. (227/0/0 chyb)
589680 % hotovo, 4:54:56 uplynulo. (228/0/0 chyb)
589681 % hotovo, 4:55:00 uplynulo. (229/0/0 chyb)
589682 % hotovo, 4:55:03 uplynulo. (230/0/0 chyb)
589683 % hotovo, 4:55:07 uplynulo. (231/0/0 chyb)
591388 % hotovo, 4:55:14 uplynulo. (232/0/0 chyb)
591389 % hotovo, 4:55:17 uplynulo. (233/0/0 chyb)
591390 % hotovo, 4:55:21 uplynulo. (234/0/0 chyb)
591391 % hotovo, 4:55:25 uplynulo. (235/0/0 chyb)
593092 % hotovo, 4:55:32 uplynulo. (236/0/0 chyb)
593093 % hotovo, 4:55:35 uplynulo. (237/0/0 chyb)
593094 % hotovo, 4:55:39 uplynulo. (238/0/0 chyb)
593095 % hotovo, 4:55:42 uplynulo. (239/0/0 chyb)
594804 % hotovo, 4:55:50 uplynulo. (240/0/0 chyb)
594805 % hotovo, 4:55:53 uplynulo. (241/0/0 chyb)
594806 % hotovo, 4:55:57 uplynulo. (242/0/0 chyb)
594807 % hotovo, 4:56:00 uplynulo. (243/0/0 chyb)
3033732% hotovo, 4:56:50 uplynulo. (244/0/0 chyb)
3033733% hotovo, 4:56:53 uplynulo. (245/0/0 chyb)
3033734% hotovo, 4:56:57 uplynulo. (246/0/0 chyb)
3033735% hotovo, 4:57:00 uplynulo. (247/0/0 chyb)
3035440% hotovo, 4:57:08 uplynulo. (248/0/0 chyb)
3035441% hotovo, 4:57:11 uplynulo. (249/0/0 chyb)
3035442% hotovo, 4:57:15 uplynulo. (250/0/0 chyb)
3035443% hotovo, 4:57:18 uplynulo. (251/0/0 chyb)
3037144% hotovo, 4:57:25 uplynulo. (252/0/0 chyb)
3037145% hotovo, 4:57:29 uplynulo. (253/0/0 chyb)
3037146% hotovo, 4:57:32 uplynulo. (254/0/0 chyb)
3037147% hotovo, 4:57:36 uplynulo. (255/0/0 chyb)
3040764% hotovo, 4:57:43 uplynulo. (256/0/0 chyb)
3040765% hotovo, 4:57:47 uplynulo. (257/0/0 chyb)
3040766% hotovo, 4:57:50 uplynulo. (258/0/0 chyb)
3040767% hotovo, 4:57:54 uplynulo. (259/0/0 chyb)
3042468% hotovo, 4:58:01 uplynulo. (260/0/0 chyb)
3042469% hotovo, 4:58:04 uplynulo. (261/0/0 chyb)
3042470% hotovo, 4:58:08 uplynulo. (262/0/0 chyb)
3042471% hotovo, 4:58:11 uplynulo. (263/0/0 chyb)
3044176% hotovo, 4:58:18 uplynulo. (264/0/0 chyb)
3044177% hotovo, 4:58:22 uplynulo. (265/0/0 chyb)
3044178% hotovo, 4:58:26 uplynulo. (266/0/0 chyb)
3044179% hotovo, 4:58:29 uplynulo. (267/0/0 chyb)
3045884% hotovo, 4:58:36 uplynulo. (268/0/0 chyb)
3045885% hotovo, 4:58:40 uplynulo. (269/0/0 chyb)
3045886% hotovo, 4:58:43 uplynulo. (270/0/0 chyb)
3045887% hotovo, 4:58:47 uplynulo. (271/0/0 chyb)
3047592% hotovo, 4:58:54 uplynulo. (272/0/0 chyb)
3047593% hotovo, 4:58:58 uplynulo. (273/0/0 chyb)
3047594% hotovo, 4:59:01 uplynulo. (274/0/0 chyb)
3047595% hotovo, 4:59:05 uplynulo. (275/0/0 chyb)
3049296% hotovo, 4:59:12 uplynulo. (276/0/0 chyb)
3049297% hotovo, 4:59:15 uplynulo. (277/0/0 chyb)
3049298% hotovo, 4:59:19 uplynulo. (278/0/0 chyb)
3049299% hotovo, 4:59:22 uplynulo. (279/0/0 chyb)
3058036% hotovo, 4:59:33 uplynulo. (280/0/0 chyb)
3058037% hotovo, 4:59:36 uplynulo. (281/0/0 chyb)
3058038% hotovo, 4:59:40 uplynulo. (282/0/0 chyb)
3058039% hotovo, 4:59:43 uplynulo. (283/0/0 chyb)
3064864% hotovo, 4:59:53 uplynulo. (284/0/0 chyb)
3064865% hotovo, 4:59:57 uplynulo. (285/0/0 chyb)
3064866% hotovo, 5:00:00 uplynulo. (286/0/0 chyb)
3064867% hotovo, 5:00:04 uplynulo. (287/0/0 chyb)
3066568% hotovo, 5:00:11 uplynulo. (288/0/0 chyb)
3066569% hotovo, 5:00:15 uplynulo. (289/0/0 chyb)
3066570% hotovo, 5:00:18 uplynulo. (290/0/0 chyb)
3066571% hotovo, 5:00:22 uplynulo. (291/0/0 chyb)
3071688% hotovo, 5:00:35 uplynulo. (292/0/0 chyb)
3071689% hotovo, 5:00:39 uplynulo. (293/0/0 chyb)
3071690% hotovo, 5:00:42 uplynulo. (294/0/0 chyb)
3071691% hotovo, 5:00:46 uplynulo. (295/0/0 chyb)
3073396% hotovo, 5:00:53 uplynulo. (296/0/0 chyb)
3073397% hotovo, 5:00:57 uplynulo. (297/0/0 chyb)
3073398% hotovo, 5:01:00 uplynulo. (298/0/0 chyb)
3073399% hotovo, 5:01:04 uplynulo. (299/0/0 chyb)
3077012% hotovo, 5:01:11 uplynulo. (300/0/0 chyb)
3077013% hotovo, 5:01:14 uplynulo. (301/0/0 chyb)
3077014% hotovo, 5:01:18 uplynulo. (302/0/0 chyb)
3077015% hotovo, 5:01:21 uplynulo. (303/0/0 chyb)
3080424% hotovo, 5:01:30 uplynulo. (304/0/0 chyb)
3080425% hotovo, 5:01:34 uplynulo. (305/0/0 chyb)
3080426% hotovo, 5:01:37 uplynulo. (306/0/0 chyb)
3080427% hotovo, 5:01:41 uplynulo. (307/0/0 chyb)
3083840% hotovo, 5:01:50 uplynulo. (308/0/0 chyb)
3083841% hotovo, 5:01:53 uplynulo. (309/0/0 chyb)
3083842% hotovo, 5:01:57 uplynulo. (310/0/0 chyb)
4136832% hotovo, 5:02:35 uplynulo. (311/0/0 chyb)
4136833% hotovo, 5:02:39 uplynulo. (312/0/0 chyb)
4136834% hotovo, 5:02:42 uplynulo. (313/0/0 chyb)
4138540% hotovo, 5:02:51 uplynulo. (314/0/0 chyb)
4138541% hotovo, 5:02:55 uplynulo. (315/0/0 chyb)
4138542% hotovo, 5:02:58 uplynulo. (316/0/0 chyb)
4138543% hotovo, 5:03:02 uplynulo. (317/0/0 chyb)
4140244% hotovo, 5:03:09 uplynulo. (318/0/0 chyb)
4140245% hotovo, 5:03:12 uplynulo. (319/0/0 chyb)
4140246% hotovo, 5:03:16 uplynulo. (320/0/0 chyb)
4140247% hotovo, 5:03:19 uplynulo. (321/0/0 chyb)
     10% hotovo, 5:23:19 uplynulo. (322/0/0 chyb)

[Pepan35]

Vytáhl jsem tedy sata disk Samsung EVO na kterém zůstal fs btrfs a na kterém mi mizel subvolumes

btrfs scrub status /mnt/ssd1:

UUID:             291c975a-f784-441d-ab69-f608269b102c
Scrub started:    Sun Apr  6 22:47:13 2025
Status:           finished
Duration:         0:00:57
Total to scrub:   28.63GiB
Rate:             514.39MiB/s
Error summary:    no errors found

[LarryL]

Co s tím? Kde je ta pointa, že raději používáš FS bez checksumů, který ti může nevědomky ztrácet data, místo abys použil FS s checksumy? Jestli už nemáš logy k BTRFS, abys zjistil v čem jsi měl problém a nechceš to už zkoumat, tak přejdi na ZFS.

[Max]

Scrub ti nezkontroluje strukturu, jen data a metadata, takže v případě chyby struktury fs poukazovat na to, že scrub prochází, je nesouvisející.
Zdar Max

[xxl]

No výborně. To to trvalo. Tak ještě udělej btrfs check.

[Pepan35]

Opening filesystem to check...
Checking filesystem on /dev/sda1
UUID: 291c975a-f784-441d-ab69-f608269b102c
[1/8] checking log skipped (none written)
[2/8] checking root items
[3/8] checking extents
[4/8] checking free space tree
[5/8] checking fs roots
[6/8] checking only csums items (without verifying data)
[7/8] checking root refs
[8/8] checking quota groups skipped (not enabled on this FS)
found 30668664832 bytes used, no error found
total csum bytes: 29874556
total tree bytes: 77119488
total fs tree bytes: 42188800
total extent tree bytes: 2506752
btree space waste bytes: 9098396
file data blocks allocated: 30591545344
 referenced 30588182528

[xxl]

Já tedy žádnou chybu nevidím. A tohle je tedy ten disk, kde ti mizel subvolume /@home ? Můžeš si vylistovat subvolumy a zjistit, jestli se tam onen @home nachází.

btrfs subvolume list /mnt/bla

[Pepan35]

ID 256 gen 730 top level 5 path @
ID 258 gen 327 top level 5 path @root
ID 259 gen 22 top level 5 path @srv
ID 260 gen 714 top level 5 path @cache
ID 261 gen 728 top level 5 path @tmp
ID 262 gen 730 top level 5 path @log
ID 263 gen 23 top level 256 path var/lib/portables
ID 264 gen 23 top level 256 path var/lib/machines

[xxl]

No jo, není.

A myslíš, že když ho teď vytvoříš, tak že tam zítra nebude? Jen tak mýrnyx týrnyx? Myslím tím, že jako pokud po vytvoření subvolumu ihned nevyhodíš pojistky, neodpojíš disk nebo tak něco.

Tomu btrfs na tvém disku nic není. Je tam uloženo 29 GB. Celkem 6 subvolumů, to je úplné nic, proti tomu, co to zvládá. Ještě bys sem schválně mohl hodit

btrfs filesystem usage /mnt/bla

abychom tedy viděli percentuální obsazenost disku.

Taky schválně můžeš projet log, co o tom tvém btrfs píše. Ono tam nejspíš celkem nic nebude. Něco jako

journalctl -S "čas připojení toho disku do systému" | grep -i btrfs

[Pepan35]

Jo díky jak jsem psal několikrát. Nepravidelně po zapnutí PC systém nenaběhl a chyběl subvolume-home. Ostatní vždy byly ok. Do vypnutí pc se nikdy žádný problém nevyskytl, nebo o něm nevím. Diskem to není, protože je nepravděpodobné aby to dělaly tři růné a navíc jeden nvme. Někdy to fungovalo i týden, jindy třeba dva dny. Subvolume obnovit neumím ani nevím jak, tak jsem pokaždé vše obnovil pomocí Clonezilly a doplnil data. Nejhorší bylo, že zrovna když jsem něco rychle potřeboval pc nenaběhl...

  Device size:                 351.56GiB
    Device allocated:             17.02GiB
    Device unallocated:          334.54GiB
    Device missing:                  0.00B
    Device slack:                    0.00B
    Used:                         13.17GiB
    Free (estimated):            337.05GiB      (min: 169.78GiB)
    Free (statfs, df):           337.05GiB
    Data ratio:                       1.00
    Metadata ratio:                   2.00
    Global reserve:               33.03MiB      (used: 0.00B)
    Multiple profiles:                  no

[pet I.]

Hmmm..., původně jsem byl přesvědčen, že se jedná o nešťastnou konfiguraci hw, ale teď mi to začíná připomínat situaci kterou kolega přivodil kolegyni. Špatně napsaný úklidový skript se špatně ošetřeným chybou konfigurace jí cca jednou za jeden až dva týdny začal mazat systém od / a přestal, když si smazal systémové knihovny. U kolegy i jinde to samozřejmě chodilo správně. Taky jsme původně podezírali hw i os a hledali jsme to přes měsíc.

Tady mi připadá, že něco jde po @home. A je možné (pouze hypotéza), že se to spouští při vypnutí a pak je věcí náhody jestli to stihne uškodit těsně před odmountováním nebo ne. Taky by to mohlo souviset s denním časem, uptimem, .... A samozřejmě to nějak souvisí s výskytem btrfs, který to potřebuje jako živnou půdu.

Teď si ještě vzpomínám, že se mi povedlo si zrušit namountovaný subvolume a on zůstal normálně přístupný a zmizel až odmountováním. Tehdy jsem si toho naštěstí všiml a obsah včas odkopíroval.

[xxl]

Ten výpis je normálně delší. A fakt je to ten stejný disk, na který jsi posílal scrub a check?

Vzhledem k tomu, jak ty informace opatrně dávkuješ, se z nich špatně věští.

Taky by mohla být zajímavá verze kernelu, verze btrfs, distribuce, log, způsob používání počítače, atp.

Jinak si ale myslím zhruba totéž, co kolega pet I. Že btrfs je v tom úplně nevinně a že za mizení tvého home subvolumu může nešťastná konfigurace čehosi. Protože kdyby byly problémy s tím, že si btrfs nerozumí s hardwarem, tak by bylo něco v logu. V takovém případě je totiž btrfs dost otravně upovídané. Když ovšem jen tak zmizí subvolume, notabene pořád ten samý, je to patrně proto, že ho něco smázlo, což je normální operace, která se neloguje. A ještě když se to samé opakovalo na více discích, tak to zavání chybou mezi klávesnicí a židlí.

[Aleš Kapica]

A ještě když se to samé opakovalo na více discích, tak to zavání chybou mezi klávesnicí a židlí.

Pozor! Ještě krůček a dostaneš od něj nálepku debila.

[Andrej]

Mám ten disk na windows, sice ne systémovej, ale je používanej a žádný problém. Tzn. bude to jak si říkal. Kombinace BTRFS a linuxu.

Jinak EVO 860 a 870 mám na linuxu v několika desítkách instalací na EXT4 a taky žádný problém. A to už x let.

Jinak na ten problémový stroj kde byl problém SSD 990 PRO 4TB po výměně za ten crucial T700 doted běží bez problémů a je tam celkem vysoké zatížení. A je tam stále BTRFS.

Problém je v definici sousloví žádný problém.

Jak se bez checksumů dat (nejen metadat) pozná, že tam není žádný problém?

Skrytý problém a žádný problém jsou zcela odlišné situace, ač na první pohled vypadají podobně.

[pavele]

A jakého výrobce disků preferuješ ty?

[Andrej]

Tahle otázka je kravina století. Už je to tady snad třikrát v tomhle vlákně.

Je to takový hloupý pseudo-argument ve stylu: „Hele, ty mi říkáš, že se mi nemají pod rukama ztrácet data??? Tak mi laskavě doporuč, která značka mi to zajistí!!!“

Tak jo. Je čas prozradit to temné tajemství.

Není to o výrobci. Není to o typu. Je to kombinace výrobce, typu, deseti různých dodavatelů čipů, kteří se na daném typu podíleli — což se leckdy liší i v rámci jediného typu, ve snaze snižovat výrobní náklady —, bugů ve firmwaru, které možná opravila aktualizace a možná taky ne, řadičů, kabelů, RAM — a ne, tím nemyslím tu RAM, kterou můžu prověřit memtestem nebo která má prostě normálně ECC, jak to má být, nýbrž RAM na všech těch mnoha zařízeních, která jsou součástí úložiště…

Zkrátka: Pokud mi hardware od roku 2016 do dneška běží s Btrfs RAID6 bez chybičky, takového hardwaru bych se rád držel.

Jenom kdybych ho nemusel nahradit za hovnovější! Což musím, protože přece jenom se kapacita a spotřeba energie jaksi vyvíjí a kromě toho nechci zkoušet, jak dlouho hardware vydrží v provozu, než konečně selže. To je zbytečně stresující a vyhnutelné.

Takže tak. Vyzkoušet, mít v pořádku zálohy, když to funguje, držet se toho, když to selhává (ale to je fakt asi tak 1‰ případů a zdroj flamebaitů typu původního dotazu), bez milosti to nahradit. Protože žádných ušetřených pět korun padesát nenahradí ztracená data.

Jiná možnost: Dát tam nechecksumovaný filesystém a namlouvat si, že je všechno v pořádku. A být za naprostého idiota.

[Pepan35]

JJ já být za naprostého idiota Nezlob se ale na mě to zavání btrfs fanatizmem. V práci máme okolo 150 PC a NB s Woknama a různýma ssd diskama. Za poslední dva, tři roky nestalo že by odešel ntfs disk a musel se dávat nový. Pokud byl nějaký problém byl vždy na vině sw. Víš co by bylo problémů u toho kvanta Windowsáků. Ano někdy se občas disk posere, ale vzhledem k tomu počtu uživatelů je to zanedbatelné. Proč by to v Linuxu a jeho fs mělo být jiné?

[Aleš Kapica]

Promiň. Nechci být hrubý. Ale jdi už prosím tě se svými moudry do prdele. Dokud žena jela na linuxu, měla pravidelné zálohy a všechno bylo fajn. Od té doby co používá školní notebook z widlema kouká jak sůva z nudlí, když ji říkám, že flashky umírají a že by se měla postarat, aby jí ty data zálohovali, jinak bude v loji. Jenomže to by musela jít za těmi jejich IT „experty”, takže to vypadá, že o ty data v dohledné době přijde.

Takže si zapiš prosím jednu pro vždy za uši: „Na vině není nikdy software, ani hardware, ale vždy jen lidská blbost.”

[Peter Golis]

Na doplnenie si dovolím zacitovať klasiku.

[Pepan35]

Taky nechci být hrubý ale "„Na vině není nikdy software, ani hardware, ale vždy jen lidská blbost.” tak s takovými moudry také běž tam kam jsi mě poslal. Ty a Golis jste opravdoví blbci. Proč mluvíš o svojí ženě se školním notebookem? Proč mluvíš o zálohování dat? Mluvím já o dceři která má taky vyfasovanej školní nb s Woknama? Můžeš mi říct kdy a kde jsem si stěžoval že jsem ztratil nějaká data?? Funguju od 286 s DOSem a NIKDY jsem neztatil žádná data protože používám zálohování. Proč mi to tedy připomínáš?

Jestli jsi nečetl vlákno tak se tu někdo ptal jestli je BTRFS nahovno. Já reagoval že ano, protože na mojí konfiguraci PC je také BTRFS nepoužitelný. Důvody jsem napsal a nebudu opakovat. To že jsem asi vyžral asi poměrně vzácný případ kdy se ASI můj HW nesnáší s tímto FS jsem taky napsal. Dokonalé řešení pro mě jsem taky napsal. Žádal jsem od tebe, nebo Golise nějakou radu, nebo pomoc? Nežádal protože naštěstí ji nepotřebuji. Tak co prudíš a reaguješ. To ti vadí že jsem spokojený. Věnuj se někomu jinému, já napsal jenom a pouze svůj názor a svoji zkušenost.

Klidně se věnuj s Golisem jinému vláknu vedle "Dotaz: Ako interpretovat smart hodnoty?" a doporuč tazateli ať na disk dá BTRFS a na smart data se vysere protože lžou. BTRFS mu jako jediný fs ukáže kdy přesně mu data na starym disku shnijou.

[Aleš Kapica]

Jestli jsi nečetl vlákno tak se tu někdo ptal jestli je BTRFS nahovno.

Jediný, kdo tu mlel o hovnech jsi ty. A pokud nevěříš, tak si dej prohledat obsah téhle diskuze.

Žádal jsem od tebe, nebo Golise nějakou radu, nebo pomoc? Nežádal protože naštěstí ji nepotřebuji. Tak co prudíš a reaguješ.

Protože reaguješ jako kokot a ta diskuze začala tvým výblitkem na adresu souborového systému o kterém víš kulové, ale hlavně že sis plivnul. Tak se pak nediv, když si pak s chutí plivnem taky.

[Pepan35]

Tak si ty debile přečti diskuzi ještě jednou. Kde jsem napsal že je BTRFS systém nahovno? To konstatoval, nebo se ptal tazatel. Já se ptal jak zjistit že můj hw je nahovno. Nejsem zakomlexovaný BTRFS fanatik jako ty a vím že je možná jenom můj hw je příčinou. S jiným by to bylo ok.

„Na vině není nikdy software, ani hardware, ale vždy jen lidská blbost.” To fakt může napsat kretén tvého formátu Taková moudra uděluj někomu kdo ti to žere. Já určitě ne!

[Want]

Rak poslouchej ty vulgární hovado. Chováš se v téhle diskuzi jak totální píčus, nemáš sebereflexe co by se za nehet vlezlo a neumíš prohledat ani webovou stránku. Tak se nediv že tu jsi za blbce. Děláš si to sám.

[Pepan35]

Na hrubý pytel hrubá záplata. Ulevilo se ti?

[Aleš Kapica]

Přesně tak. Došlo ti, že to tvrzení je platné recipročně?

[Pepan35]

tak si taky ulev Třeba ti zdvihne tvoje nízké seběvědomí. Patříš taky dávno mezi ty kteří škodí Abclinuxu.

[Aleš Kapica]

Zato s tebou to tu začalo jen kvést. O výši mého sebevědomí se obávat nemusíš. Je úměrná tomu, co vím.

[Pepan35]

Tak ta úměrnost znalostem Linuxu podle mě zcela neodpovídá. Možná něco jiného je "Kdo si stojí na vedení", ale to je trochu jiná oblast!

[Aleš Kapica]

Ty jsi ten poslední, kdo by to byl schopen objektivně posoudit. Vždyť nejsi schopen se ani zaregistrovat na tenhle server.

[Pepan35]

Ano nejsem schopen se zaregistrovat na tenhle server a nemíním to udělat právě kvůli takovým lidem jako jsi například ty.

[Want]

Měl jsi na to 20 let, tak se nevymlouvej. A nikdo tě tu nedrží, tak si nestěžuj.

[Pepan35]

Tak třeba mě tu neregistrovaného držíš ty s Kapicou a Golisem co by výkvět Abclinuxu

[Aleš Kapica]

Kdejaký zdejší troll zde ví, že Want je můj anonymní nick, který používám když sem lezu z mobilu. Proto ho taky s oblibou sem tam někdo zneužije. Rozeznáš to ale celkem snadno – troll nezvládá diakritiku a gramatiku. Překlepům na mobilu bohužel zabránit nelze. To už by si za těch 20 let taky mohl vědět.

[Pepan35]

Kapico tím jsi mě dostal! I když stejně jako v případě Wanta jenom prudíš a o linuxu víš houby a dokonce oba jste zaslepení btrfs-filové tak mě to nepapadlo dát si to dohromady. Holt se na stará kolena musím hodně učit. Naštěstí tady na Abclinuxu ještě několik ochotných a slušných lidí kterých si velice vážím a kteří mají svoji přirozenou autoritu.

[Aleš Kapica]

Holt se na stará kolena musím hodně učit.

To teda musíš. Já se učím neustále. Jenom se obávám jestli ti to půjde, když máš takový problém pochopit, mě neplatí za plkání na abclinuxu.

[Pepan35]

Njn to učení vzhledem k mojemu věku mi už moc nejde to máš pravdu. Sice nevím kde jsi přišel k tomu že nechápu že se v tvym mladym věku živíš prací a že tě neplatí za plkání na abclinuxu, ale budiž. Btw ty poslední blogy Buřt a ten poslední jsou fakt dobrý. Ty se ti opravdu povedly.

Ty jsi expert, který nejenom, že se nezvládá naučit něco o systému, který používá, ale dokonce si ani nenechá poradit. A ještě svoji neschopnost házíš na všechny a všechno okolo.

[Pepan35]

a copak jsi mi ty dobrého poradil? Kdyby jsi uměl číst tak jak znovu opakuji jsem žádnou radu nežádal. Popsal jsem jenom vlastní zkušenost s BTRFS.

[Max]

Když ti padnou windows, nebo ti v nich začně něco zlobit, tak to může být právě způsobeno chybou na disku. Nemusí nutně odejít celý disk a celý disk být v režimu nepřečtení.
Zdar Max