Administrace komentářů

Já osobně bych asi v takové situaci zkusil udělat bitovou kopii na jiné SSD ... a zkusil bych scrub tam.

To jsem neprováděl, protože nemám volný SSD disk a už bych to asi nervově nevydržel. Zálohu mám.

Rozžehnal jsem se s daty a provedl jsem

# btrfs check --repair --init-csum-tree /dev/sda2

Mraky nějakých hlášení typu:

ref mismatch on [1462395944960 16384] extent item 1, found 0
backref 1462395944960 root 7 not referenced back 0x5589f4da0d80
incorrect global backref count on 1462395944960 found 1 wanted 0
backpointer mismatch on [1462395944960 16384]
owner ref check failed [1462395944960 16384]
repair deleting extent record: key [1462395944960,169,0]
Repaired extent references for 1462395944960

Missing extent item in extent tree for disk_bytenr 153016442880, num_bytes 249856
Missing extent item in extent tree for disk_bytenr 153395150848, num_bytes 315392
Missing extent item in extent tree for disk_bytenr 111695663104, num_bytes 303104
Missing extent item in extent tree for disk_bytenr 153028231168, num_bytes 372736

root 2311 inode 340 errors 800, odd csum item
root 2312 inode 260 errors 800, odd csum item
root 2314 inode 257 errors 800, odd csum item
ERROR: errors found in fs roots
found 643762806784 bytes used, error(s) found
total csum bytes: 624818280
total tree bytes: 3404529664
total fs tree bytes: 2564161536
total extent tree bytes: 203603968
btree space waste bytes: 481775282
file data blocks allocated: 1954303500288
 referenced 784495185920

WARNING: reserved space leaked, flag=0x4 bytes_reserved=1146880
extent buffer leak: start 1095305838592 len 16384
WARNING: dirty eb leak (aborted trans): start 1095305838592 len 16384
extent buffer leak: start 1097453273088 len 16384
WARNING: dirty eb leak (aborted trans): start 1097453273088 len 16384
extent buffer leak: start 1095306100736 len 16384

Nemám to všechno, zapomněl jsem to zaznamenat, ale mám asi 10000 řádek z konzole. V logu během akce žádná chyba. Když jsem to viděl, říkal jsem si, že data jsou nejspíš fuč. Namontoval jsem disk (bez problůmů) a provedl jsem scrub. Úplně bez problémů. Device stats samé nuly.

Odmontoval jsem disk a provedl jsem

# btrfs check /dev/sda2

s asi takovým výsledkem

[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 1694152658944, num_bytes 61440
Missing extent item in extent tree for disk_bytenr 1692857667584, num_bytes 4096
Missing extent item in extent tree for disk_bytenr 1692857692160, num_bytes 20480

root 262 inode 370 errors d00, file extent discount, nbytes wrong, odd csum item
Found file extent holes:
	start: 4128436224, len: 53877739520

root 348 inode 988365 errors 800, odd csum item
root 348 inode 988366 errors 800, odd csum item
root 348 inode 988367 errors 800, odd csum item

root 399 inode 289145 errors 2001, no inode item, link count wrong
	unresolved ref dir 38831 index 7 namelen 17 name user-1000.journal filetype 1 errors 4, no inode ref
root 399 inode 300166 errors 2001, no inode item, link count wrong
	unresolved ref dir 2869 index 21 namelen 18 name basic.target.wants filetype 2 errors 4, no inode ref

ERROR: errors found in fs roots
Opening filesystem to check...
Checking filesystem on /dev/sda2
UUID: e6497e96-c4a7-4431-868c-3f6878f753c9
found 644285390848 bytes used, error(s) found
total csum bytes: 625252300
total tree bytes: 3445374976
total fs tree bytes: 2602778624
total extent tree bytes: 205012992
btree space waste bytes: 490006298
file data blocks allocated: 2407376396288
 referenced 843735949312

Prostě mraky chyb, tohle je jen ukázka. --repair vyhodil to samé, akorát se to snažil nějak opravovat a po vícero průchodech se ustálil asi na 13000 řádcích úplně stejného výsupu. Tj. vypisoval chyby, snažil se je opravit, stále dokola to stejné.

Smarttest úplně OK. Btrfs scrub úplně OK. Btrfs check --repair, mraky chyb. Nicméně systém (notebook) nejspíš plně funkční, nepřišel jsem na nic, co by nefungovalo. Zkoušel jsem pouštět virtuální stroje, linux z cow image s vnitřním filesystémem btrfs, windows z nocow image. Ty image předtím přečkaly ty hokusy pokusy. Všechno to fungovalo. A v systémovém logu se od opravy csum-tree neobjevila žádná chyba ani varování ohledně btrfs.

Nicméně, přestalo mě to bavit, další pokusy jsem zavrhl a znovu jsem to naformátoval.

Podle mě to celé vzniklo tím vynuceným resetem virtuálních Windows spuštěných z cow image disku (což se jaksi nedoporučuje).