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 -- Could this mail be a fake? (Answer: No! - http://fortytwo.ch/gpg/intro)
On Thu, May 27, 2010 at 06:46:04PM +0200, Adrian von Bidder wrote:> 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.> 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? >No not really, atm it''s just for us developers.> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 On Thursday 27 May 2010 20.15:53 Josef Bacik wrote:> On Thu, May 27, 2010 at 06:46:04PM +0200, Adrian von Bidder wrote: > > 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. > > > 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? > > No not really, atm it''s just for us developers. > > > 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-- Wenn Windows 98 die Antwort ist, wie blöd ist dann die Frage gewesen?
Josef Bacik <josef@redhat.com> writes:>> 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"? -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html