Taddeusz Posted October 13, 2018 Share Posted October 13, 2018 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? Quote Link to comment
JorgeB Posted October 13, 2018 Share Posted October 13, 2018 Please post your diagnostics: Tools -> Diagnostics Quote Link to comment
Taddeusz Posted October 13, 2018 Author Share Posted October 13, 2018 (edited) 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, 2018 by Taddeusz Quote Link to comment
JorgeB Posted October 13, 2018 Share Posted October 13, 2018 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. Quote Link to comment
Taddeusz Posted October 14, 2018 Author Share Posted October 14, 2018 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 Quote Link to comment
JorgeB Posted October 14, 2018 Share Posted October 14, 2018 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. Quote Link to comment
Taddeusz Posted October 14, 2018 Author Share Posted October 14, 2018 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 Quote Link to comment
Taddeusz Posted October 14, 2018 Author Share Posted October 14, 2018 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. Quote Link to comment
JorgeB Posted October 14, 2018 Share Posted October 14, 2018 Try it, but it doesn't make much sense the scrub not detecting the error. Quote Link to comment
Taddeusz Posted October 14, 2018 Author Share Posted October 14, 2018 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? Quote Link to comment
JorgeB Posted October 14, 2018 Share Posted October 14, 2018 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. Quote Link to comment
JorgeB Posted October 15, 2018 Share Posted October 15, 2018 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 Quote Link to comment
Taddeusz Posted October 15, 2018 Author Share Posted October 15, 2018 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. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.