Hi Nikolay. Thanks.
On Wed, 2018-02-21 at 08:34 +0200, Nikolay Borisov wrote: > This looks like the one fixed by > e8f1bc1493855e32b7a2a019decc3c353d94daf6 . It's tagged for stable so > you > should get it eventually. Another consequence of this was that I couldn't sync/umount or shutdown anymore properly. And now after hard reset I found this in the kernel logs: Feb 21 14:49:29 heisenberg kernel: BTRFS warning (device dm-0): csum failed root 257 ino 49103564 off 2076672 csum 0xe1f5b83a expected csum 0x0e0adf97 mirror 1 Feb 21 14:49:29 heisenberg kernel: BTRFS warning (device dm-0): csum failed root 257 ino 49103505 off 4464640 csum 0x0b661193 expected csum 0xe9c939a3 mirror 1 Feb 21 14:49:45 heisenberg kernel: BTRFS warning (device dm-0): csum failed root 257 ino 47533539 off 139264 csum 0x4d704dc7 expected csum 0x2303d9f7 mirror 1 That may be totally unrelated to the above bug (I just may not have noticed it earlier), but I checked that now: # btrfs inspect-internal inode-resolve 49103564 / //usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.9.2 # btrfs inspect-internal inode-resolve 49103505 / //usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.9.2 # btrfs inspect-internal inode-resolve 47533539 / //usr/lib/python2.7/dist-packages/libxml2.py AFAIU inode-resolve should give me the files belonging to the above broken inodes? # dpkg -S //usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.9.2 libqt5widgets5:amd64: /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.9.2 # dpkg -S //usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.9.2 libqt5gui5:amd64: /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.9.2 # dpkg -S //usr/lib/python2.7/dist-packages/libxml2.py python-libxml2: /usr/lib/python2.7/dist-packages/libxml2.py Which belong to these Debian packages. # debsums -asc libqt5widgets5 libqt5gui5 python-libxml2 # Which are apparently correct (as it regards Debian, which keeps some hash sums of "all" it's package's files). Interestingly, another: # btrfs scrub start -Br /dev/disk/by-label/system scrub done for b6050e38-716a-40c3-a8df-fcf1dd7e655d scrub started at Wed Feb 21 14:52:45 2018 and finished after 00:23:25 total bytes scrubbed: 629.61GiB with 0 errors # returned no further error... What does that mean now? How could btrfs correct the error (did it - I have no RAID or so)? Anything further I should do to check the consistency of my filesystem? Thanks, Chris. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html