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.
next prev parent 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.