btrfsck: doesn't correct errors
Heyho!
(This is using btrfs from Debian's 2.6.32 2.6.32-3-kirkwood kernel (-9
package; btrfs tools is v0.19-16-g075587c)
A few observations about btrfsck:
a btrfsck run on a 2T volume (4 disks) on a QNAP appliance (512M ram) got killed by Mr. OOM Killer. Initially, I was quite surprised. I'm only moderately surprised now since it might well be that I forgot to enable swap.
A btrfsck run (on a remote machine this time, with nbd) showed quite a few errors like:
root 268 inode 34001 errors 2000
root 268 inode 34002 errors 2000
root 268 inode 34074 errors 2000
root 268 inode 34102 errors 2000
root 268 inode 34103 errors 2000
root 268 inode 34104 errors 2000
root 268 inode 34132 errors 2000
root 268 inode 34133 errors 2000
2nd observation: am I supposed to know what this means?
And 3rd observation: btrfsck apparently doesn't correct this kind of error. Running btrfsck again still shows the error.
cheers
-- vbi
Signature · 1 line
Could this mail be a fake? (Answer: No! - http://fortytwo.ch/gpg/intro)
Quoted 5 lines · Adrian von Bidder
Heyho!
(This is using btrfs from Debian's 2.6.32 2.6.32-3-kirkwood kernel (-9
package; btrfs tools is v0.19-16-g075587c)
Quoted 7 lines
A few observations about btrfsck:
a btrfsck run on a 2T volume (4 disks) on a QNAP appliance (512M ram) got killed by Mr. OOM Killer. Initially, I was quite surprised. I'm only moderately surprised now since it might well be that I forgot to enable swap.
Yes, btrfsck keeps the entire extent tree in memory, so the bigger the fs, the more RAM it's going to use.
Quoted 11 lines
A btrfsck run (on a remote machine this time, with nbd) showed quite a few errors like:
root 268 inode 34001 errors 2000
root 268 inode 34002 errors 2000
root 268 inode 34074 errors 2000
root 268 inode 34102 errors 2000
root 268 inode 34103 errors 2000
root 268 inode 34104 errors 2000
root 268 inode 34132 errors 2000
root 268 inode 34133 errors 2000
Quoted 2 lines
2nd observation: am I supposed to know what this means?
No not really, atm it's just for us developers.
Quoted 3 lines
And 3rd observation: btrfsck apparently doesn't correct this kind of error. Running btrfsck again still shows the error.
Yeah btrfsck doesn't fix problems yet. Thats being worked on. Thanks,
Josef
Thanks for taking the time to answer.
(And what I didn't say: as a pure user, for desktop and for the backup appliance mentioned, I'm using btrfs so far without any problems. I'm not hard on it on purpose, but stuff like failed wake-up after suspend to ram does happen occasionally on the laptop.)
cheers
-- vbi
Quoted 37 lines · On Thursday 27 May 2010 20.15:53 Josef Bacik wrote:
Quoted 11 lines · Adrian von Bidder
Heyho!
(This is using btrfs from Debian's 2.6.32 2.6.32-3-kirkwood kernel (-9
package; btrfs tools is v0.19-16-g075587c)A few observations about btrfsck:
a btrfsck run on a 2T volume (4 disks) on a QNAP appliance (512M ram) got killed by Mr. OOM Killer. Initially, I was quite surprised. I'm only moderately surprised now since it might well be that I forgot to enable swap.
Yes, btrfsck keeps the entire extent tree in memory, so the bigger the fs, the more RAM it's going to use.
Quoted 11 lines
A btrfsck run (on a remote machine this time, with nbd) showed quite a few errors like:
root 268 inode 34001 errors 2000
root 268 inode 34002 errors 2000
root 268 inode 34074 errors 2000
root 268 inode 34102 errors 2000
root 268 inode 34103 errors 2000
root 268 inode 34104 errors 2000
root 268 inode 34132 errors 2000
root 268 inode 34133 errors 2000Quoted 1 line
2nd observation: am I supposed to know what this means?
No not really, atm it's just for us developers.
Quoted 2 lines
And 3rd observation: btrfsck apparently doesn't correct this kind of error. Running btrfsck again still shows the error.
Yeah btrfsck doesn't fix problems yet. Thats being worked on. Thanks,
Josef
Signature · 1 line
Wenn Windows 98 die Antwort ist, wie blöd ist dann die Frage gewesen?
Quoted 4 lines · Josef Bacik
Quoted 1 line
a btrfsck run on a 2T volume [with] 512M ram got [OOM killed].
Yes, btrfsck keeps the entire extent tree in memory, so the bigger the fs, the more RAM it's going to use.
Is that an inherent property of btrfsck, or do you intend to address it sometime before btrfs is labelled "production ready"?