Question about a specific error.
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?
I'm running btrfs-progs 4.3.1 on kernel 4.3.3 (at least, that's the version that works right now, I see the same errors on 4.4.1, but I have other issues there that are (hopefully) unrelated to BtRFS).
Quoted 11 lines · Austin S. Hemmelgarn
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 indexI 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.
Hugo.
Quoted 3 lines
I'm running btrfs-progs 4.3.1 on kernel 4.3.3 (at least, that's the version that works right now, I see the same errors on 4.4.1, but I have other issues there that are (hopefully) unrelated to BtRFS).
Signature · 4 lines
Hugo Mills | Charting the inexorable advance of Western hugo@... carfax.org.uk | syphilisation. http://carfax.org.uk/ | PGP: E2AB1DE4 |
Quoted 11 lines · Austin S. Hemmelgarn
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 indexI 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?
Is it consistent between boots? I have a system with SSD where if I boot with rd.break=pre-mount, and run btrfs check, I sometimes get a long string of similar messages. But upon reboot they don't happen anymore.
Signature · 1 line
Chris Murphy
Quoted 14 lines · Chris Murphy
Quoted 11 lines · Austin S. Hemmelgarn
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 indexI 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?
Quoted 5 lines
Is it consistent between boots? I have a system with SSD where if I boot with rd.break=pre-mount, and run btrfs check, I sometimes get a long string of similar messages. But upon reboot they don't happen anymore.
I've only checked twice, but the output is identical, so they appear to be consistent. What seems interesting about this to me is that while most of them are in the same directory, about 1/4 are just scattered around the FS. None of it is anything critical though, and the system runs just fine (or at least, it appears to, most of the issues I'm having appear to be GPU related, and don't seem to have anything to do with BTRFS).
Quoted 8 lines · Hugo Mills
Quoted 7 lines · Austin S. Hemmelgarn
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
Quoted 8 lines
Quoted 4 lines
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.
Out of curiosity, do you happen to know if this is how btrfs check reports orphaned inodes, or is this something else entirely?
Quoted 14 lines · Austin S. Hemmelgarn
Quoted 13 lines · Hugo Mills
Quoted 11 lines · Austin S. Hemmelgarn
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 indexI 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?
Quoted 5 lines
Quoted 3 lines
Yes, those are errors I'd expect btrfs check --repair to handle
properly.Out of curiosity, do you happen to know if this is how btrfs check reports orphaned inodes, or is this something else entirely?
I don't know, sorry.
Hugo.
Signature · 4 lines
Hugo Mills | We teach people management skills by examining hugo@... carfax.org.uk | characters in Shakespeare. You could look at http://carfax.org.uk/ | Claudius's crisis management techniques, for PGP: E2AB1DE4 | example. Richard Smith-Jones, Slings and Arrows
Quoted 8 lines · Hugo Mills
Quoted 7 lines · Austin S. Hemmelgarn
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
Quoted 8 lines
Quoted 4 lines
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.
Quoted 21 lines · Austin S. Hemmelgarn
Quoted 11 lines · Hugo Mills
Quoted 9 lines · Austin S. Hemmelgarn
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 indexQuoted 9 lines
Quoted 4 lines
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.
Quoted 10 lines
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
Signature · 1 line
Chris Murphy
Quoted 34 lines · Chris Murphy
Quoted 21 lines · Austin S. Hemmelgarn
Quoted 11 lines · Hugo Mills
Quoted 9 lines · Austin S. Hemmelgarn
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 indexQuoted 9 lines
Quoted 4 lines
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.Quoted 10 lines
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.
Quoted 4 lines
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.
Signature · 4 lines
Hugo Mills | You are not stuck in traffic: you are traffic hugo@... carfax.org.uk | http://carfax.org.uk/ | PGP: E2AB1DE4 | German ad campaign
Chris Murphy posted on Wed, 03 Feb 2016 14:17:06 -0700 as excerpted:
Quoted 4 lines
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
You likely know this but didn't explicitly state it, and for others...
AFAIK, errors is a bitmask, so errors 2001 is the same bitmask error as 2000, plus another, errors 0001.
But I'm not sure what errors those actually are, either. The errors bitmask is obviously targeted at devs who can read the code and see what each bit means, and to my knowledge there's no table posted on the wiki or wherever for non-devs to look it up.
Signature · 3 lines
Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Quoted 40 lines · Hugo Mills
Quoted 34 lines · Chris Murphy
Quoted 21 lines · Austin S. Hemmelgarn
Quoted 11 lines · Hugo Mills
Quoted 9 lines · Austin S. Hemmelgarn
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 indexQuoted 9 lines
Quoted 4 lines
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.Quoted 10 lines
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.
Quoted 4 lines
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
Quoted 4 lines
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 ofcmds-check.c. 2000 isI_ERR_SOME_CSUM_MISSING, 1 isI_ERR_NO_INODE_ITEM.
OK, that makes some sense. Although I'm still curious why a file with some of the checksums missing would:
1) Not have any apparent errors during regular usage (no errors in dmesg or syslog, and access worked just fine) when it's not set to nodatasum or nocow.
2) Be reported in a manner that seems to imply it's orphaned (which I would expect for Chris' case, as I_ERR_NO_INODE_ITEM sounds like a type of orphan to me).