Dotaz: btrfs - Missing extent item ...

[rastos]

Příloha:

• btrfs.log (7992 bytů)

Pri mountovaní BTRFS mi v dmesg pribudne

[ 8383.975256] BTRFS info (device sdb1): has skinny extents
[ 8383.982305] BTRFS info (device sdb1): bdev /dev/sdb1 errs: wr 0, rd 0, flush 0, corrupt 1, gen 0
[ 8384.031848] BTRFS info (device sdb1): enabling ssd optimizations

a "btrfs check" povie:

[1/7] checking root items
[2/7] checking extents
[3/7] checking free space cache
[4/7] checking fs roots
Missing extent item in extent tree for disk_bytenr 16596041728, num_bytes 4096
Missing extent item in extent tree for disk_bytenr 76934107136, num_bytes 106496
...
Missing extent item in extent tree for disk_bytenr 89601380352, num_bytes 4096
[5/7] checking only csums items (without verifying data)
[6/7] checking root refs
[7/7] checking quota groups skipped (not enabled on this FS)
Opening filesystem to check...
Checking filesystem on /dev/sdb1
UUID: 8581dc84-e882-4523-b71b-c6716e2bfa29
found 145329205248 bytes used, no error found
total csum bytes: 132829812
total tree bytes: 8998354944
total fs tree bytes: 8661811200
total extent tree bytes: 182419456
btree space waste bytes: 1443277968
file data blocks allocated: 5952141643776
 referenced 687409426432

scrub žiadne problémy nehlási, smartctl tiež a "btrfs check --repair" nepomohol. Má niekto nápad, čo s tým?

Odpovědi

[Jendа]

Odlejt data, vytvořit znova, nalejt zpátky a doufat že to zase chvíli vydrží. Případně zkusit memtest jestli to není vadnou RAM.

scrub žiadne problémy nehlási

Tohle přece není možné!</troll>

[rastos]

Odlejt data, ...

To je trocha nepraktické, lebo tam mám N snapshotov, mnohé ako zálohy. Robiť na to btrfs send by znamenalo veľa miesta pre duplikované dáta , robiť btrfs send -p ... by znamenalo veľa ručnej práce. A to je ešte otázne či tým nebudem odlievať corruptnuté dáta, nie?

[GeorgeWH]

Korumpovane data tam nebudu. Ved je to predsa btrfs! A ten korupciu nepozna.

[Max]

Ale pozná, stačí vadný řadič, kabel, problémové ssd, které rádo ztrácí výpadkem proudu data atd. To jsou všechno věci, kterým jde těžko zabránit, protože systém dostane všechno ok, ale na pozadí se spouští mixér dat.
Zdar Max

[[Jooky]]

Tohle přece není možné!</troll>

Scrub nekontroluje volne miesto. Je mozne, ze to poskodenie je niekde vo volnom priestore a preho ho scrub "nenajde".

[Jendа]

btrfs a btrfs check čte volné místo? Co s ním dělá a co znamená že je volná místo corruptnuté? To Missing extent item in extent tree for disk_bytenr 16596041728, num_bytes 4096 nezní úplně jako volné místo…

[Max]

Mohu se zeptat, co používáš za model disku?
Zdar Max

[rastos]

Tento konkrétny je 500GB Samsung SSD 860 starý asi rok.

[Max]

To jsi nezvolil moc dobře, řekl bych...
Samsung 860/870 SSDs Continue Causing Problems For Linux Users.
A celkově se to se Samsungem dost táhne a u serie 800 docela dost. Nemáš v dmesg něco podezřelého?
Zdar Max
PS: Samsung je důvod, proč jsem se na jeho lep nikdy nenechal nachytat a dal jsem vždy přednost středním a vyšším řadám Crucialu (kompatibilita, stabilita a minimální poruchovost na top úrovni, aktuálně tedy MX500 SATA a P.5 NVMe)

[rastos]

Trocha si ma vydesil Ale vyzerá to tak, že problém je s NCQ TRIM a ak tomu dobre rozumiem, tak v novších jadrách je Samsung 860 zaradený do blacklistu a teda sa táto funkcionalita nepoužíva. Samozrejme dopadom je nižší výkon, ale v mojom prípade to nejak moc nevadí.

Nemáš v dmesg něco podezřelého?

Napr. čo?

[    1.798522] ata4.00: supports DRM functions and may not be fully accessible
[    1.798526] ata4.00: ATA-11: Samsung SSD 860 EVO 500GB, RVT04B6Q, max UDMA/133
[    1.798897] ata4.00: 976773168 sectors, multi 1: LBA48 NCQ (depth 32), AA
[    1.799660] ata5.00: configured for UDMA/100
[    1.800981] ata4.00: Features: Trust Dev-Sleep NCQ-sndrcv
[    1.801259] ata4.00: supports DRM functions and may not be fully accessible
[    1.803874] ata4.00: configured for UDMA/133
...
[    4.469436] scsi 3:0:0:0: Direct-Access     ATA      Samsung SSD 860  4B6Q PQ: 0 ANSI: 5
...
[    4.469559] sd 3:0:0:0: [sdb] 976773168 512-byte logical blocks: (500 GB/466 GiB)
[    4.469563] sd 3:0:0:0: [sdb] Write Protect is off
[    4.469565] sd 3:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[    4.469569] sd 3:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    4.469580] sd 3:0:0:0: [sdb] Preferred minimum I/O size 512 bytes
[    4.469704] ata4.00: Enabling discard_zeroes_data
[    4.471308] scsi 4:0:0:0: CD-ROM            ASUS     DRW-24F1ST   a   1.00 PQ: 0 ANSI: 5
[    4.480863]  sdb: sdb1 sdb2
[    4.481797] sd 3:0:0:0: [sdb] supports TCG Opal
[    4.481800] sd 3:0:0:0: [sdb] Attached SCSI disk
...
[   11.391199] BTRFS: device fsid 4bfef5c9-ce01-4a39-b7b9-86865e1f4ab5 devid 1 transid 2310 /dev/sdb2 scanned by udevd (818)
...
[   49.687188] BTRFS info (device sdb1): has skinny extents
[   49.692102] BTRFS info (device sdb1): bdev /dev/sdb1 errs: wr 0, rd 0, flush 0, corrupt 1, gen 0
[   49.740737] BTRFS info (device sdb1): enabling ssd optimizations

[Max]

Zmíněná chyba "jen" v TRIM a NCQ neznamená jen problémy s výkonem, ale i potencionálním random data loss . Každopádně nevím o žádném potvrzení, že někomu k data loss došlo. Na druhou stranu, jak jinak si vysvětlit podobné záhadné poškozování btrfs, když spousta lidí nemá ani ťuk po hafec letech provozu včetně vysokých zátěží.
Podle mě podobné problémy vznikají na úrovni hw. Já sám mám všude btrfs a na ntb v 95% případů vypínám ntb držením power tlačítka, prostě force power off, jelikož je to pomalý ntb a chvátám a nechci, aby mi vypínání dobíhalo v batožině.
Jinak v tom dmesg nevidím nic podezřelého.
Zdar Max

[Max]

Jinak ještě dodám, že tady na abc to už někdo také řešil, viz: #471768. A co tam vidíš, že má za disk? Přesně tak .
Zdar Max