I recently migrated an ext4 filesystem on a lvm volume to btrfs using btrfs-convert. After mounting it later, I realized that there were some problems with it.
As soon as I did something that involved writing data to the disk, it was forced readonly, as of
dmesg. I did some research and ran
scrub, which found two files with csum errors. Unfortunately one of them was the
ext2_saved for rollback. I thought that deleting the files with the csum errors would resolve the problem. So I deleted the backup and the other file.
scrub did not find any errors. But when mounting, I now get the following message:
bdev /dev/mapper/my-volume errs: wr 0, rd 0, flush 0, corrupt 608, gen 0. It seems like I can now write to the disk (renaming a file worked, I didn't do further tests yet).
Should this message worry me or can it be ignored? Or even better: how can I find the cause of it? scrub and even btrfs check --repair didn't find any issues.
I ran a Memtest and checked for badblocks. Both tests came out clean.
I also updated my Kernel to
4.9.9-gentoo. When compiling the Kernel I found out that I had the
CONFIG_BTRFS_FS_CHECK_INTEGRITY option enabled, aka
Btrfs with integrity check tool compiled in (DANGEROUS). I now disabled this option.
After this I tried to launch Chrome - which obviously did something on the mentioned disk. Shortly after I read something like this in dmesg:
*Some stacktrace* btrfs_finish_ordered_io:someline errno=-95 unknown forced readonly
Umounting left me with this message:
cleaner transaction attach returned -30
I also had these when I still had the checksum errors that now are resolved. Now I can't find a reason for them.
I ran a scrub again, which passed with 0 errors.
btrfs check --repair /dev/mapper/my-volume, it now
fixed discount file extents for some inodes, which apparently were newly occurred errors as the same command before the update didn't find anything.
I'll probably have to move the data away in readonly to another disk and just format the thing.
Copying the data away in readonly worked, without losing data, so it seems. Looks like the conversion from ext4 to btrfs isn't working perfectly yet.
Kernel: 4.4.39-gentoo; now: 4.9.9-gentoo btrfs-progs v.4.9