On 13-09-2016 16:49, Austin S. Hemmelgarn wrote:
I'd be kind of curious to see the results from btrfs check run without
repair, but I doubt that will help narrow things down any further.
Attached.
As of right now, the absolute first thing I'd do is check your logs to
see if you can find any indication of errors from the disk itself. I
don't think it's likely, but it's worth checking.
Will do.
The couple of lines just before the crash in the attached kernel log
would indicate to me that some of the metadata is corrupted. There are
two likely possibilities for how that happened:
1. Running with no extra space for new chunks to be allocated is not a
common use case, so it's not well tested, and it wouldn't surprise me if
some accounting falls apart in that situation.
Indeed. I periodically remove old snapshots and check for disk space,
bit I guess I ran a bit too near the limit this time.
2. You might have bad RAM or a bad PSU. This is the second thing you
should check after checking to see if the disk is OK, as either will
likely cause any repair attempts to make things worse. RAM is pretty
easy to check, but for a PSU you need a proper testing device. You can
get such a device on Amazon or similar sites for about 25USD, and it's
generally worth having around for troubleshooting.
Understood.
This notebook has occasional failures when resuming from hibernation. I
suppose, from the point of view of the filesystem, this corresponds to
an unclean reboot.
Assuming your disk and RAM are good, the next thing to do would be try
and get the filesystem into a more usable state. The best option for
this is to expand the filesystem if possible. Given that you're running
right near capacity, I'd suggest at least 16G of extra space if
possible. If that isn't a viable solution for you, the other option is
to delete some of the oldest snapshots (Ideally enough that you have at
least a few GB of extra space in the data chunks and a few hundred MB in
the metadata chunks), then add a 4-8GB device to the FS temporarily (a
ramdisk or flash drive works well for this), and run a full balance. If
you're lucky, this will fix any metadata that's messed up, and the
system should be usable. If not, it shouldn't make things any worse,
and you probably want to look at btrfs restore to copy out the data to a
new filesystem (ideally a bigger one).
I will try this next.
Thanks for the help!
Cesar
checking extents
parent transid verify failed on 160420773888 wanted 181826 found 181573
parent transid verify failed on 160420773888 wanted 181826 found 181573
parent transid verify failed on 160420773888 wanted 181826 found 181573
parent transid verify failed on 160420773888 wanted 181826 found 181573
Ignoring transid failure
leaf parent key incorrect 160420773888
parent transid verify failed on 160420773888 wanted 181826 found 181573
Ignoring transid failure
leaf parent key incorrect 160420773888
parent transid verify failed on 160420773888 wanted 181826 found 181573
Ignoring transid failure
leaf parent key incorrect 160420773888
parent transid verify failed on 160420773888 wanted 181826 found 181573
Ignoring transid failure
leaf parent key incorrect 160420773888
parent transid verify failed on 160420773888 wanted 181826 found 181573
Ignoring transid failure
leaf parent key incorrect 160420773888
parent transid verify failed on 160420773888 wanted 181826 found 181573
Ignoring transid failure
leaf parent key incorrect 160420773888
parent transid verify failed on 160420773888 wanted 181826 found 181573
Ignoring transid failure
leaf parent key incorrect 160420773888
parent transid verify failed on 160420773888 wanted 181826 found 181573
Ignoring transid failure
leaf parent key incorrect 160420773888
parent transid verify failed on 160420773888 wanted 181826 found 181573
Ignoring transid failure
leaf parent key incorrect 160420773888
parent transid verify failed on 160418889728 wanted 181826 found 181572
parent transid verify failed on 160418889728 wanted 181826 found 181572
parent transid verify failed on 160418889728 wanted 181826 found 181572
parent transid verify failed on 160418889728 wanted 181826 found 181572
parent transid verify failed on 160420741120 wanted 181826 found 181573
parent transid verify failed on 160420741120 wanted 181826 found 181573
parent transid verify failed on 160420741120 wanted 181826 found 181573
parent transid verify failed on 160420741120 wanted 181826 found 181573
Ignoring transid failure
leaf parent key incorrect 160420741120
bad block 160420741120
Errors found in extent allocation tree or chunk allocation
parent transid verify failed on 160420773888 wanted 181826 found 181573
Ignoring transid failure
parent transid verify failed on 160418889728 wanted 181826 found 181572
parent transid verify failed on 160418889728 wanted 181826 found 181572
parent transid verify failed on 160420741120 wanted 181826 found 181573
Ignoring transid failure
Error: could not find btree root extent for root 1183
Checking filesystem on /dev/sdb5
UUID: 79862c20-d0b0-4ffa-a9af-e3a40868a243
