I just changed hardware this morning and I noticed that I am getting BTRFS csum warnings. It seems to coincide with me using my Windows 10 VM. This particular VM's vdisk is located on my cache drive. I've run a btrfs scrub and it reported no errors. What should I do next? Should the vdisk have checksum disabled?

Please post your diagnostics: Tools -> Diagnostics

17 minutes ago, johnnie.black said:

Please post your diagnostics: Tools -> Diagnostics

Sorry, I meant to include that in my initial post.

 

unraid-diagnostics-20181013-1802.zip

Edited October 13, 20187 yr by Taddeusz

There's no problem having checksum enable for vdisks but it is strange scrub not reporting errors, please run a new scrub a post the output here as well as new diags grabbed after the scrub finishes.

1 hour ago, johnnie.black said:

There's no problem having checksum enable for vdisks but it is strange scrub not reporting errors, please run a new scrub a post the output here as well as new diags grabbed after the scrub finishes.

 ⚡ root@unRAID  ~  btrfs scrub start -B /dev/sdc1
scrub done for e10d5ffd-c05a-43db-b41e-e314f951b97a
	scrub started at Sat Oct 13 19:28:53 2018 and finished after 00:06:10
	total bytes scrubbed: 119.09GiB with 0 errors

 

 

unraid-diagnostics-20181013-1936.zip

Try an offline check, with the array stopped:

 

btrfs check --readonly --check-data-csum /dev/sdc1

 

If still no errors I would backup/format/restore the cache.

 

5 hours ago, johnnie.black said:

Try an offline check, with the array stopped:

 

btrfs check --readonly --check-data-csum /dev/sdc1

 

If still no errors I would backup/format/restore the cache.

 

Yeah, still no errors:

 ⚡ root@unRAID  ~  btrfs check --readonly --check-data-csum /dev/sdc1
Checking filesystem on /dev/sdc1
UUID: e10d5ffd-c05a-43db-b41e-e314f951b97a
checking extents
checking free space cache
checking fs roots
checking csums against data
checking root refs
found 117959417856 bytes used, no error found
total csum bytes: 97811724
total tree bytes: 549404672
total fs tree bytes: 348897280
total extent tree bytes: 63881216
btree space waste bytes: 132519728
file data blocks allocated: 1556583190528
 referenced 94754942976

 

The warnings seem to always come from the same inode:

 

Oct 14 09:16:59 unRAID kernel: BTRFS warning (device sdc1): csum failed root 5 ino 382101 off 2453172224 csum 0x2fbab702 expected csum 0x7ea1a571 mirror 1
Oct 14 09:16:59 unRAID kernel: BTRFS warning (device sdc1): csum failed root 5 ino 382101 off 2453536768 csum 0xba96ca2e expected csum 0x9be02cc0 mirror 1
Oct 14 09:17:01 unRAID kernel: BTRFS warning (device sdc1): csum failed root 5 ino 382101 off 2453172224 csum 0x9be02cc0 expected csum 0x7ea1a571 mirror 1
Oct 14 09:17:01 unRAID kernel: BTRFS warning (device sdc1): csum failed root 5 ino 382101 off 2453536768 csum 0x42186b7f expected csum 0x9be02cc0 mirror 1

That would probably be the vdisk file then. I'll try moving the vdisk from the cache and back on.

Try it, but it doesn't make much sense the scrub not detecting the error.

41 minutes ago, johnnie.black said:

Try it, but it doesn't make much sense the scrub not detecting the error.

It was worth a try but it didn't do anything. I had made a change a couple weeks ago moving all my Docker containers to point directly to /mnt/cache rather than /mnt/user. I also changed the path to my VM's vdisk. I changed my vdisk location back to pointing at /mnt/user and the checksum warnings seem to have gone away.

 

Why would there be a difference between the two?

1 hour ago, Taddeusz said:

Why would there be a difference between the two?

It shouldn't, but this issue doesn't make much sense from the beginning, so not sure what's going on.

One thing I forgot, if it happens again try to see what the affected file is by using the inode number, e.g. for the earlier error:

 

find /mnt/cache -inum 382101

 

44 minutes ago, johnnie.black said:

One thing I forgot, if it happens again try to see what the affected file is by using the inode number, e.g. for the earlier error:

 

find /mnt/cache -inum 382101

 

Ok, thank you, I'll keep that in mind.