All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: Pete <pete@petezilla.co.uk>, linux-btrfs@vger.kernel.org
Subject: Re: Snapshots slowing system
Date: Fri, 18 Mar 2016 14:54:54 -0400	[thread overview]
Message-ID: <56EC4EFE.5000105@gmail.com> (raw)
In-Reply-To: <56EC4612.4030206@petezilla.co.uk>

On 2016-03-18 14:16, Pete wrote:
> On 03/18/2016 09:17 AM, Duncan wrote:
>
>> So bottom line regarding that smartctl output, yeah, a new device is
>> probably a very good idea at this point.  Those smart attributes indicate
>> either head slop or spin wobble, and some errors and command timeouts and
>> retries, which could well account for your huge slowdowns.  Fortunately,
>> it's mostly backup, so you have your working copy, but if I'm not mixing
>> up my threads, you have some media files, etc, on a different partition
>> on it as well, and if you don't have backups elsewhere, getting them onto
>> something else ASAP is a very good idea, because this drive does look to
>> be struggling, and tho it could continue working in a low usage scenario
>> for some time yet, it could also fail rather quickly, as well.
>>
>
> This disk is one of a pair or raid1 disks which hold the data on my
> system.  As you summised the machine is generally on 24x7 as it can just
> get on with backups and some data grabbing and crunching on its own.
>
> This is a set up of 2 x 3TB disks completely dedicated to btrfs.  I'm
> wondering if the failing one is the older one wrenched out of a USB
> enclosure as it was cheaper than a desktop one or whether it was the
> desktop drive?  Still academic.  I have 1.37TB unallocated, 720GB free
> estimated.  I'm therefore wondering whether I opt for the cheapest
> reasonable desktop drive, a NAS drive advertised for 24x7 or whether I
> pick a wallet frightening 'enterprise drive' as it might be twice as
> much as the standard desktop but will give me less grief in the long
> term.  Probably one for comp.os.linux.hardware.
Personally, I find that desktop drives generally do fine for 24/7 usage 
as long as things aren't constantly being written to and read from them. 
  For a write-once-read-many workload like most backup setups, there's 
not usually a huge advantage to getting high end disks unless you can't 
be there to replace them relatively soon after they fail (one disk in a 
RAID set failing puts more load on the other disk, thus increasing it's 
chance of also failing).  Desktop disks usually do provide similarly low 
error rates as higher end disks, the big difference is in how they 
handle errors.  Desktop drives will (usually) keep retrying a read on a 
bad sector for multiple minutes before giving up, while NAS drives will 
return an error almost immediately, and enterprise drives will let you 
configure how long it will retry.
>
>
>>> Confused.  I'm getting one SSD which I intend to use raid0.  Seems to me
>>> to make no sense to split it in two and put both sides of raid1 on one
>>> disk and I reasonably think that you are not suggesting that.  Or are
>>> you assuming that I'm getting two disks?  Or are you saying that buying
>>> a second SSD disk is strongly advised?  (bearing in mind that it looks
>>> like I might need another hdd if the smart field above is worth worrying
>>> about).
>>
>> Well, raid0 normally requires two devices.  So either you mean single
>> mode on a single device, or you're combining it with another device (or
>> more than one more) to do raid0.
>
> Sorry, I confused raid0 with single.  The _lone_ system disk contains
> the root partition, it is btrfs in single mode.
Don't feel bad, I made this mistake myself a couple of times at first too.
>
>
>
>> So btrfs raid1 has data integrity and repair features that aren't
>> available on normal raid1, and thus is highly recommended.
>>
>> But, raid1 /does/ mean two copies of both data and metadata (assuming of
>> course you make them both raid1, as I did), and if you simply don't have
>> room to do it that way, you don't have room, highly recommended tho it
>> may be.
>
> This looks like a strong recommendation to get a second SSD for the root
> partition and go raid1.  Are SSDs more flakey that hdd or are you just a
> strong believer in the integrity of raid1?
Generally, SSD's have better reliability in harsh conditions than HDD's, 
they can safely handle a wider temperature range, and are pretty much 
unaffected by vibration.  They fail in different ways however, so advice 
for preventing data loss on HDD's doesn't necessarily apply to SSD's.

Overall though, it really depends on what brand you get.  As of right 
now, the top three brands of SSD as far as quality IMHO are Intel, 
Samsung, and Crucial.  I usually go with Crucial myself because they are 
almost on-par with the other two, give more deterministic performance 
(their peak performance is often lower, but I'm willing to sacrifice a 
bit of performance to get consistency across operating conditions), and 
cost less (sometimes less than half as much as an equivalently sized 
Intel or Samsung SSD) .  Kingston, SanDisk, ADATA, Transcend, and Micron 
are generally OK, but sometimes have issues with data loss when they 
lose power unexpectedly (this likely won't be an issue for you though if 
you have a system that's on 24/7).  The only brand I would actively 
avoid is OCZ, as they've had numerous issues with reliability and data 
integrity over multiple revisions of multiple models of SSD.

  reply	other threads:[~2016-03-18 18:55 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-14 23:03 Snapshots slowing system pete
2016-03-15 15:52 ` Duncan
2016-03-15 22:29   ` Peter Chant
2016-03-16 11:39     ` Austin S. Hemmelgarn
2016-03-17 21:08       ` Pete
2016-03-18  9:17         ` Duncan
2016-03-18 11:38           ` Austin S. Hemmelgarn
2016-03-18 17:58             ` Pete
2016-03-18 23:58             ` Duncan
2016-03-18 18:16           ` Pete
2016-03-18 18:54             ` Austin S. Hemmelgarn [this message]
2016-03-19  0:59               ` Duncan
2016-03-19  1:15             ` Duncan
  -- strict thread matches above, loose matches on Subject: below --
2016-03-12 13:01 pete
2016-03-13  3:28 ` Duncan
2016-03-11 20:03 Pete
2016-03-11 23:38 ` boris

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=56EC4EFE.5000105@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=pete@petezilla.co.uk \
    /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.