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.
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.
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!
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.
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
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->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->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?
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
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
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!
