All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: Anand Jain <anand.jain@oracle.com>,
	Stefan Malte Schumacher <stefan.m.schumacher@gmail.com>,
	linux-btrfs@vger.kernel.org, David Sterba <dsterba@suse.cz>
Subject: Re: Monitoring Btrfs
Date: Tue, 18 Oct 2016 08:39:07 -0400	[thread overview]
Message-ID: <a813c70b-e230-726e-e0bc-e8f15848cc44@gmail.com> (raw)
In-Reply-To: <c40e1675-f002-b2e4-b252-c5e17200f72a@oracle.com>

On 2016-10-17 23:23, Anand Jain wrote:
>
>
>>> I would like to monitor my btrfs-filesystem for missing drives.
>
>> This is actually correct behavior, the filesystem reports that it should
>> have 6 devices, which is how it knows a device is missing.
>
>  Missing - means missing at the time of mount. So how are you planning
> to monitor a disk which is failed while in production ?
No, in `btrfs fi show` it means that it can't find the device.  All that 
`fi show` does is print out what info it can find about the filesystem, 
nothing more, nothing less.  It's trivial to see from the output (two 
different ways I might add) that you're missing devices and how many you 
still have.  The only way without poking at the FS directly to figure 
out how many devices the FS is supposed to have (or at least, how many 
it thinks it should have) is the device count output by `btrfs fi show`.

Now, for production usage, you have three things you should be monitoring:
1. Output from `btrfs dev stats`.  This reports per-device error 
counters, and is one of the best ways to see if something is wrong, and 
also gives you a decent indicator of exactly what is wrong.
2. Status from regular scrub operations.  Pretty self explanatory.
3. SMART status of the underlying devices themselves.  This will catch 
pre-failure conditions, and the direct access from smartctl will error 
out when the drive has failed to the point of not being present.

You can additionally monitor:
1. Filesystem flags.  These will change when the filesystem goes 
degraded, and it's actually good practice for any filesystem, not just 
BTRFS.
2. Total filesystem size.  If this changes without manual intervention, 
something is seriously wrong.

  reply	other threads:[~2016-10-18 12:39 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-17 16:44 Monitoring Btrfs Stefan Malte Schumacher
2016-10-17 17:23 ` Austin S. Hemmelgarn
2016-10-18  3:23   ` Anand Jain
2016-10-18 12:39     ` Austin S. Hemmelgarn [this message]
2016-10-18 21:36       ` Anand Jain
2016-10-19 11:15         ` Austin S. Hemmelgarn
2016-10-19 13:06           ` Anand Jain
2016-10-19 13:33             ` Austin S. Hemmelgarn
2016-10-19 21:38               ` Anand Jain
2016-10-17 17:41 ` Zygo Blaxell
2016-10-17 17:55 ` Kyle Manna
2016-10-17 20:40 ` Chris Murphy
2016-10-18 12:41   ` Austin S. Hemmelgarn
2016-10-19 22:46 ` Stefan Malte Schumacher

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=a813c70b-e230-726e-e0bc-e8f15848cc44@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=anand.jain@oracle.com \
    --cc=dsterba@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=stefan.m.schumacher@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.