btrfs csum error

chiefpete · October 17, 2014, 3:57am

During a reboot of my computer, the computer froze and I was forced to press the reset button. After powering back on everything seemed fine, until I noticed that the root file system is mounted read only.

A dmesg showed:


[83.050170] parent transid verify failed on 18533310464 wanted 671804 found 671808
   83.057370] parent transid verify failed on 18533310464 wanted 671804 found 671808
   83.245608] parent transid verify failed on 18533310464 wanted 671804 found 671808
   83.245819] parent transid verify failed on 18533310464 wanted 671804 found 671808
   83.252334] parent transid verify failed on 18533310464 wanted 671804 found 671808
   83.252489] parent transid verify failed on 18533310464 wanted 671804 found 671808

Followed by:


152.550318] BTRFS info (device sda1): csum failed ino 23545 off 0 csum 1738709224 expected csum 3677127208

I rebooted and noted that the root file system was mounted rw but then a short time later was mounted ro.

I rebooted with my opensus rescue USB.

I ran btrfs scrub start on the filesystem and get the following output:

total bytes scrubbed: 33.36GiB with 1 errors
error details: csum=1
corrected errors: 0, uncorrected erors: 1, unverified errors: 0

dmesg shows:

btrfs: bdev /dev/sda1 errs; wr 0, rd 0, flush 0, corrupt 2, gen 0
btrfs: checksum error at logical 29875421184 on dev /dev/sda1, sector 63871840, root 5, inode 23545, offset 0, length4096, links 1 path: var/lib/Packagekit/transactions.db

How do I repair the filesystem?

System info:

opensuse 13.1
kernel 3.17.0-1.gc467423-desktop - amd64
kde 4.14.2

Thanks for any assistance.

Mark

malcolmlewis · October 17, 2014, 4:33am

On Fri 17 Oct 2014 02:06:01 AM CDT, chiefpete wrote:

During a reboot of my computer, the computer froze and I was forced to
press the reset button. After powering back on everything seemed fine,
until I noticed that the root file system is mounted read only.

A dmesg showed:

Code:

[83.050170] parent transid verify failed on 18533310464 wanted 671804
found 671808 83.057370] parent transid verify failed on 18533310464
wanted 671804 found 671808 83.245608] parent transid verify failed
on 18533310464 wanted 671804 found 671808 83.245819] parent transid
verify failed on 18533310464 wanted 671804 found 671808 83.252334]
parent transid verify failed on 18533310464 wanted 671804 found 671808
83.252489] parent transid verify failed on 18533310464 wanted
671804 found 671808 --------------------

Followed by:

Code:

152.550318] BTRFS info (device sda1): csum failed ino 23545 off 0
csum 1738709224 expected csum 3677127208

I rebooted and noted that the root file system was mounted rw but then a
short time later was mounted ro.

I rebooted with my opensus rescue USB.

I ran btrfs scrub start on the filesystem and get the following output:

total bytes scrubbed: 33.36GiB with 1 errors
error details: csum=1
corrected errors: 0, uncorrected erors: 1, unverified errors: 0

dmesg shows:

btrfs: bdev /dev/sda1 errs; wr 0, rd 0, flush 0, corrupt 2, gen 0
btrfs: checksum error at logical 29875421184 on dev /dev/sda1, sector
63871840, root 5, inode 23545, offset 0, length4096, links 1 path:
var/lib/Packagekit/transactions.db

How do I repair the filesystem?

System info:

opensuse 13.1
kernel 3.17.0-1.gc467423-desktop - amd64
kde 4.14.2

Thanks for any assistance.

Mark

Hi
Have you tried;


btrfs check --fix-crc

AFAIK, it may pay to take an image first, see man btrfs-image.

–
Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890)
openSUSE 13.1 (Bottle) (x86_64) GNOME 3.10.1 Kernel 3.11.10-21-desktop
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

chiefpete · October 17, 2014, 5:30am

I’ve created the image.

The command

btrfs check --fix-crc

is not a recognized option.

I have:

--repair             try to repair the filesystem
--init-csum-tree     create a new CRC tree
--init-extent-tree   create a new extent tree

I’m not sure which is the least destructive.

The man pages on the opensuse rescue system don’t even list the check command.

Mark

malcolmlewis · October 17, 2014, 5:47am

Hi
An older version of btrfs… v3.16 offers --check-data-csum

What about the command;


btrfs-show-super -a /dev/sda1

Do you see [match]?

Not sure about the --repair check option

chiefpete · October 17, 2014, 6:00am

Yes, match shows up.


linux:~ # btrfs-show-super -a /dev/sda1superblock: bytenr=65536, device=/dev/sda1
---------------------------------------------------------
csum            0xf103ebd3 [match]
bytenr            65536
flags            0x1
magic            _BHRfS_M [match]
fsid            827f3aef-76a4-46ea-a582-e59a9e6815ea
label            
generation        672061
root            847618048
sys_array_size        226
chunk_root_generation    460729
root_level        1
chunk_root        20971520
chunk_root_level    1
log_root        0
log_root_transid    0
log_root_level        0
total_bytes        42951770112
bytes_used        33387495424
sectorsize        4096
nodesize        4096
leafsize        4096
stripesize        4096
root_dir        6
num_devices        1
compat_flags        0x0
compat_ro_flags        0x0
incompat_flags        0x41
csum_type        0
csum_size        4
cache_generation    672061
dev_item.uuid        4b71b80a-7d91-44b0-a33d-4f8f9e27aaa7
dev_item.fsid        827f3aef-76a4-46ea-a582-e59a9e6815ea [match]
dev_item.type        0
dev_item.total_bytes    42951770112
dev_item.bytes_used    42951770112
dev_item.io_align    4096
dev_item.io_width    4096
dev_item.sector_size    4096
dev_item.devid        1
dev_item.dev_group    0
dev_item.seek_speed    0
dev_item.bandwidth    0
dev_item.generation    0


superblock: bytenr=67108864, device=/dev/sda1
---------------------------------------------------------
csum            0x5162c31d [match]
bytenr            67108864
flags            0x1
magic            _BHRfS_M [match]
fsid            827f3aef-76a4-46ea-a582-e59a9e6815ea
label            
generation        672061
root            847618048
sys_array_size        226
chunk_root_generation    460729
root_level        1
chunk_root        20971520
chunk_root_level    1
log_root        0
log_root_transid    0
log_root_level        0
total_bytes        42951770112
bytes_used        33387495424
sectorsize        4096
nodesize        4096
leafsize        4096
stripesize        4096
root_dir        6
num_devices        1
compat_flags        0x0
compat_ro_flags        0x0
incompat_flags        0x41
csum_type        0
csum_size        4
cache_generation    672061
dev_item.uuid        4b71b80a-7d91-44b0-a33d-4f8f9e27aaa7
dev_item.fsid        827f3aef-76a4-46ea-a582-e59a9e6815ea [match]
dev_item.type        0
dev_item.total_bytes    42951770112
dev_item.bytes_used    42951770112
dev_item.io_align    4096
dev_item.io_width    4096
dev_item.sector_size    4096
dev_item.devid        1
dev_item.dev_group    0
dev_item.seek_speed    0
dev_item.bandwidth    0
dev_item.generation    0

chiefpete · October 17, 2014, 2:27pm


 linux:~ # btrfs check --repair /dev/sda1enabling repair mode
Checking filesystem on /dev/sda1
UUID: 827f3aef-76a4-46ea-a582-e59a9e6815ea
checking extents
btrfs: cmds-check.c:2063: check_owner_ref: Assertion `!(rec-&gt;is_root)' failed.
Aborted


 linux:~ # btrfs check --init-csum-tree /dev/sda1Creating a new CRC tree
Checking filesystem on /dev/sda1
UUID: 827f3aef-76a4-46ea-a582-e59a9e6815ea
checking extents
Reinit crc root
found 0 bytes used err is 0
total csum bytes: 0
total tree bytes: 0
total fs tree bytes: 0
total extent tree bytes: 0
btree space waste bytes: 0
file data blocks allocated: 0
 referenced 0
Btrfs v0.20-rc1+20130701


 linux:~ # mount /dev/sda1 /mnt/repair
mount: mount /dev/sda1 on /mnt/repair failed: Cannot allocate memory


 linux:~ # btrfs check --repair /dev/sda1enabling repair mode
parent transid verify failed on 590475264 wanted 672064 found 672061
parent transid verify failed on 590475264 wanted 672064 found 672061
parent transid verify failed on 590475264 wanted 672064 found 672061
parent transid verify failed on 590475264 wanted 672064 found 672061
Ignoring transid failure
Checking filesystem on /dev/sda1
UUID: 827f3aef-76a4-46ea-a582-e59a9e6815ea
checking extents
btrfs: cmds-check.c:2063: check_owner_ref: Assertion `!(rec-&gt;is_root)' failed.
Aborted

The filesystem appears to be toast.

I did find on the btrfs mail list a thread on corruption associated with 3.17 kernel. - This may have been the trigger. The thread talks about read only snapshots, I’m only using snapper to automatically create snapshots and don’t think that they are read only.

Prior to executing #btrfs check --init-csum-tree I was able browse the snapshots. Could I have set one of these snapshots as the default and delete the newer snapshots?

Mark

chiefpete · October 17, 2014, 2:34pm

I was able to restore the filesystem with the btrfs-image that I took prior to the --init-csum-tree

So if there is a way to use a snapshot, that would save me from doing a reinstall.

Thanks

Mark

malcolmlewis · October 17, 2014, 5:04pm

On Fri 17 Oct 2014 12:36:01 PM CDT, chiefpete wrote:

I was able to restore the filesystem with the btrfs-image that I took
prior to the --init-csum-tree

So if there is a way to use a snapshot, that would save me from doing a
reinstall.

Thanks

Mark

Hi
As in rollback?
http://activedoc.opensuse.org/book/opensuse-reference/chapter-4-snapshotsrollback-with-snapper

–
Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890)
openSUSE 13.1 (Bottle) (x86_64) GNOME 3.10.1 Kernel 3.11.10-21-desktop
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!