On 2015-11-24 12:06, Vincent Olivier wrote:
You get bonus points for being on a reasonably up-to-date kernel and userspace :)Hi,Woke up this morning with a kernel panic (for which I do not have details). Please find below the output for btrfs check. Is this normal ? What should I do ? Arch Linux 4.2.5. Btrfs-utils 4.3.1. 17x4TB RAID10.
This is actually a pretty tame check result for a filesystem that's been through kernel panic. I think everything listed here is safe for check to fix, but I would suggest waiting until the devs provide opinions before actually running with --repair. I would also suggest comparing results between the different devices in the FS, if things are drastically different, you may have issues that check can't fix on it's own.
These next two lines are errors, but I'm not 100% certain if it's safe to have check fix them:[root@3dcpc5 ~]# btrfs check /dev/sdk Checking filesystem on /dev/sdk UUID: 6a742786-070d-4557-9e67-c73b84967bf5 checking extents checking free space cache checking fs roots
This next one is also an error, and I am fairly certain that it's safe to have check fix as long as the number at the end is not too big.root 5 inode 1341670 errors 400, nbytes wrong root 11406 inode 1341670 errors 400, nbytes wrong
found 19328809638262 bytes used err is 1
The rest is just reference info
The only other thing I know that's worth mentioning is that if the numbers on these next two lines don't match, you may be missing some writes from right before the crash.total csum bytes: 18849042724 total tree bytes: 27389886464 total fs tree bytes: 4449746944 total extent tree bytes: 3075457024 btree space waste bytes: 2880474254
file data blocks allocated: 19430708535296 referenced 20123773407232
smime.p7s
Description: S/MIME Cryptographic Signature
