On Wed, Feb 03, 2016 at 02:17:06PM -0700, Chris Murphy wrote: > On Tue, Feb 2, 2016 at 6:00 AM, Austin S. Hemmelgarn > <ahferroin7@xxxxxxxxx> wrote: > > On 2016-02-01 15:21, Hugo Mills wrote: > >> > >> On Mon, Feb 01, 2016 at 02:44:24PM -0500, Austin S. Hemmelgarn wrote: > >>> > >>> In the process of trying to debug issues I'm having on one of my > >>> systems with a new kernel version, I decided to do a dry run check on > >>> the root filesystem. 'btrfs check' returned a bunch of lines like: > >>> > >>> root 257 inode XXXXXX errors 2000, link count wrong > >>> unresolved ref dir YYYYY index 53 namelen 3 name LOG filetype 0 > >>> errors 3, no dir item, no dir index > >>> > >>> I got about 20 messages like this with varying values for everything > >>> except the filetype and error counts. Based on what I can tell, these > >>> look like orphaned inodex, but I'm not certain. > >>> Is it safe to tell BTRFS to try and fix these errors? > >> > >> > >> Yes, those are errors I'd expect btrfs check --repair to handle > >> properly. > >> > > OK, it looks like things were fixed safely, but I'm not 100% certain that it > > fixed things the way it should have. All of the files it reported got moved > > to /lost+found (which makes me think it thought they were orphaned items), > > but none of the files themselves showed any issues in regular usage (they > > were all perfectly visible beforehand in the regular directory structure, > > and there were no errors accessing them). On top of that, it pulled out two > > different versions of each one, one from more than a year ago, and one > > current version. I think btrfs check may have gotten either confused or > > over-zealous and just decided it needed to pull out the current, perfectly > > fine versions of the files as well. > > The problems look different. You're reporting errors 2000. I'm seeing > errors 2001. I'm not sure what the distinction is; but in my case, > cancelling btrfs check and just rerunning it gives different results. > https://bugzilla.kernel.org/show_bug.cgi?id=111841 The "errors" field in the output of btrfs check is a hex (strange... I thought it was octal...) bit-field indicating the set of error types encountered. They're defined in #defines at the top of cmds-check.c. 2000 is I_ERR_SOME_CSUM_MISSING, 1 is I_ERR_NO_INODE_ITEM. Hugo. -- Hugo Mills | You are not stuck in traffic: you are traffic hugo@... carfax.org.uk | http://carfax.org.uk/ | PGP: E2AB1DE4 | German ad campaign
Attachment:
signature.asc
Description: Digital signature
