All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robert White <rwhite@pobox.com>
To: Erkki Seppala <flux-btrfs@inside.org>, linux-btrfs@vger.kernel.org
Subject: Re: Balance & scrub & defrag
Date: Fri, 12 Dec 2014 05:32:19 -0800	[thread overview]
Message-ID: <548AEE63.4010006@pobox.com> (raw)
In-Reply-To: <m49egs5b515.fsf@coffee.modeemi.fi>

On 12/12/2014 01:17 AM, Erkki Seppala wrote:
> Robert White <rwhite@pobox.com> writes:
>
>> You need to buy better disks. 8-)
>
> Where can one buy these better disks with reasonable prices?-) Disks are
> best thought of as consumables.

A good disk is only about 9% more expensive. So like the WD "green" 
disks were all cheap because they were (essentially) the disks that 
didn't pass the full quality suite for the higher WD lines like "caviar".

"Inexpensive" and "Cheap" are not the same thing.

Disks are not best thought of as consumables unless the data you store 
on them is discardable.

> Do you alternatively execute SMART self tests?

Indeed. If you install and activate SMART but you never run the tests 
you've done another one of those half-measures I was talking about.

The "long offline" test reads 100% of the disk surface (well, up until 
it hits an error anyway). But since none of that data has to leave the 
disk controller and go out through the interface etc it doesn't bog the 
rest of the system.

All but the oldest or cheapest drives have controllers that will "resume 
the offline test after any command" so you do

smartctl --test=long /dev/sda # or whatever

every few days and you'll know when things start to get dicy.

The one thing you do have to be watchful of is that the tests _stop_ 
when they hit the first read error, so you do have to keep up with things.

For instance I just had a pair of uncorrectable read errors. When I used 
hdparm to write the sectors, however, the disk didn't need to relocate 
the block(s) as bad. So it was some funky event on the disk itself.

Of course it's a very old disk (1525 days of power-on runtime) so two 
correctable-with-overwrite read errors isn't bad.



  reply	other threads:[~2014-12-12 13:32 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-10 22:15 Balance & scrub & defrag sys.syphus
2014-12-11  1:17 ` Robert White
2014-12-12  1:00   ` Russell Coker
2014-12-12  1:31     ` Robert White
2014-12-12  9:17       ` Erkki Seppala
2014-12-12 13:32         ` Robert White [this message]
2014-12-13  5:15         ` Zygo Blaxell
2014-12-11  8:33 ` Duncan
2014-12-12  4:32 ` Zygo Blaxell
  -- strict thread matches above, loose matches on Subject: below --
2014-12-12  9:49 Tomasz Chmielewski

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=548AEE63.4010006@pobox.com \
    --to=rwhite@pobox.com \
    --cc=flux-btrfs@inside.org \
    --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 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.