Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Austin S Hemmelgarn <ahferroin7@gmail.com>
To: Gareth Pye <gareth@cerberos.id.au>,
	linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: utils version and convert crash
Date: Tue, 1 Dec 2015 10:16:06 -0500	[thread overview]
Message-ID: <565DB9B6.6000602@gmail.com> (raw)
In-Reply-To: <CA+WRLO-1K5sRYiVQ0tEF+WUHJFSe++3fWHaqZ7ZvkhopFaWcbw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2160 bytes --]

On 2015-12-01 07:57, Gareth Pye wrote:
> Poking around I just noticed that btrfs de stats /data points out that
> 3 of my drives have some read_io_errors. I'm guessing that is a bad
> thing. I assume this would indicate bad hardware and would be a likely
> cause of system crashes.
In general, given that info, I would suggest that you do the following:
1. Run btrfs device stats -z to reset the counters (they're running 
counts stored on disk, not counts of recent errors or errors since last 
boot, so the numbers are probably over the lifetime of the filesystem 
right now).
2. Run a scrub on the filesystem (if you add -Bd, you get stats 
per-device when it's done, although it runs in the foreground).  If the 
scrub reports no errors, it's less likely that the issue is hardware 
than software (or just the system having crashed).
3. Regardless of the scrub results, use smartctl (usually found in a 
package called smartmontools or something similar) to check what the 
disk firmware thinks about how healthy the disk hardware is. 
Interpreting anything beyond the SMART attributes and the SMART health 
status is somewhat difficult without a lot of experience and some 
significant low-level knowledge of the hardware and software, but if the 
disk says it's healthy (check smartctl -H, and possibly smartctl -A), 
then it's _probably_ OK.
4. Check your kernel logs for messages about ATA link resets.  If you 
see a number of these, check your cables.  If the cables are fine 
(securely connected, don't appear damaged), then this may be an early 
indication of failing hardware (although there are other non-failure 
hardware issues this can be indicative of).

In general, read-errors are not a huge issue as long as you scrub the 
filesystem regularly (unless you get a lot in a short period of time, in 
which case you should be worried).  When you start getting write errors 
or link resets (like mentioned in step 4 above), or when the SMART 
pre-failure attributes hit their thresholds is when you should be 
getting worried and start actively looking for a replacement disk (and 
verifying your backups).


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]

  parent reply	other threads:[~2015-12-01 15:16 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-01 12:38 utils version and convert crash Gareth Pye
2015-12-01 12:57 ` Gareth Pye
2015-12-01 14:46   ` Duncan
2015-12-01 15:16   ` Austin S Hemmelgarn [this message]
2015-12-01 15:14 ` Duncan
2015-12-01 20:12   ` Gareth Pye
2015-12-01 20:30     ` Austin S Hemmelgarn
2015-12-01 22:22       ` Gareth Pye
2015-12-02  7:07         ` Gareth Pye
2015-12-02 10:01           ` Duncan
2015-12-02 12:07             ` Gareth Pye
2015-12-02 12:25             ` Austin S Hemmelgarn
2015-12-02 13:45               ` Duncan
2015-12-02 14:32                 ` Austin S Hemmelgarn
2015-12-02 22:14                   ` Gareth Pye
2016-02-28 10:23                     ` Gareth Pye

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=565DB9B6.6000602@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=gareth@cerberos.id.au \
    --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