1

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.

After rebooting, 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.


UPADTE:

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. When running 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.

UPDATE:

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.


System Info:

Kernel: 4.4.39-gentoo; now: 4.9.9-gentoo
btrfs-progs v.4.9
1

btrfs keeps per-device statistics and stores the persistently on disk. You can manually print them using btrfs device stats device|mountpoint. They are also printed on mount (at least if any of them are non-zero).

So what you're seeing is just telling you that corruption has been detected in the past; you can clear the counters with the -z flag: btrfs device stats -z /dev/mapper/my-volume.

Of course, it'd be good to find out what caused the corruption originally—I'm not sure if its a btrfs convert bug or if you have something that may continue to cause corruption (unreliable hardware). I recommend at a memory test if you're not sure.

(And, it should go without saying, but make backups—especially when using a relatively young filesystem like btrfs.)

  • I'll look for an error. I already ran badblocks which came out clean. If i come across an hardware error, I'll update my question. – rudib Feb 10 '17 at 17:20
  • sadly, a deeper error persists (the stats are fine but I can't use the disk). Please have a look at the update. – rudib Feb 11 '17 at 1:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.