linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: mount problem
Date: Wed, 24 Sep 2014 13:23:32 +0000 (UTC)	[thread overview]
Message-ID: <pan$b29db$c1fc8f39$f1e6e06c$d6b3042c@cox.net> (raw)
In-Reply-To: 20140923120641.GA27624@galliera.it

Simone Ferretti posted on Tue, 23 Sep 2014 14:06:41 +0200 as excerpted:

> we're testing BTRFS on our Debian server.  After a lot of operations
> simulating a RAID1 failure, every time I mount my BTRFS RAID1 volume the
> kernel logs these messages:
> 
> [73894.436173] BTRFS: bdev /dev/etherd/e30.20 errs:
> wr 33036, rd 0, flush 0, corrupt 2806, gen 0
> [73894.436181] BTRFS: bdev /dev/etherd/e60.28 errs:
> wr 244165, rd 0, flush 0, corrupt 1, gen 4
> 
> Everything seems to work nice but I'm courious to know what these
> messages mean (in particular what do "gen" and "corrupt" mean?).

Gen=generation.  The generation or transaction-ID (different names for 
the exact same thing) is a monotonically increasing integer that gets 
updated every time a tree update reaches all the way to the superblock.  
In the error context, it means the superblock had one generation number 
but N other blocks had a different (presumably older) generation number.

Corrupt is simply the number of blocks where the calculated checksum 
didn't match the recorded checksum, thus indicating an error.

Of course rd=read, wr=write...

In raid1 mode scrub can typically find and fix many of these errors.  My 
brtfs are mostly raid1 mode, and when I crash and reboot, scrub nearly 
always finds and fixes errors on the two btrfs (independent btrfs full-
filesystems, not subvolumes, /var/log and /home) I normally have mounted 
rw.

But do note that this is the HISTORIC count, counting all errors since 
the counts were reset.  Thus, they'll still be reported after scrub or 
whatever has fixed them.  As long as the numbers don't increase, you're 
good.  Any increase indicates additional problems.

See btrfs device stats -z to reset the numbers to zero (after printing 
them one last time).

-- 
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


  reply	other threads:[~2014-09-24 13:23 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-23 12:06 mount problem Simone Ferretti
2014-09-24 13:23 ` Duncan [this message]
2014-09-24 14:28   ` Simone Ferretti
2014-09-25  5:34     ` Duncan
  -- strict thread matches above, loose matches on Subject: below --
2011-01-12  0:25 Leonidas Spyropoulos
2011-01-12  0:48 ` Tsutomu Itoh
2011-01-12  0:58   ` Leonidas Spyropoulos
2011-01-12  1:38     ` Leonidas Spyropoulos

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='pan$b29db$c1fc8f39$f1e6e06c$d6b3042c@cox.net' \
    --to=1i5t5.duncan@cox.net \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).