linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: Major HDD performance degradation on btrfs receive
Date: Thu, 17 Mar 2016 07:00:23 +0000 (UTC)	[thread overview]
Message-ID: <pan$993a$3e6653ed$790f69a1$c396ece4@cox.net> (raw)
In-Reply-To: 1557fe0b-bbcc-c125-5220-46a56e936590@mokrynskyi.com

Nazar Mokrynskyi posted on Wed, 16 Mar 2016 05:37:02 +0200 as excerpted:

> I'm not sure what you mean exactly by searching. My first SSD died
> during waking up from suspend mode, it worked perfectly till last
> moment. It was not used for critical data at that time, but now I
> understand clearly that SSD failure can happen at any time. Having RAID0
> of 2 SSDs it 2 times more risky, so I'm not ready to lose anything
> beyond 15 minutes threshold. I'd rather end up having another HDD purely
> for backup purposes.

I understand the raid0 N times the danger part, which is why I only ever 
used raid0 on stuff like the distro packages cache that I could easily 
redownload from the net, here.

But seriously, what are you doing that you can't lose more than 15 
minutes of?  Couldn't it be even 20 minutes, or a half-hour or an hour 
with 15 minute snapshots only on the ssds (yes, I know the raid0 factor, 
but the question still applies)?

What /would/ you do if you lost a whole hour's worth of work?  Surely you 
could duplicate it in the next hour?  Or are you doing securities trading 
or something, where you /can't/ recover work at all, because by then the 
market and your world have moved on?  But in that case...

And perhaps more importantly for your data, btrfs is still considered 
"stabilizing, not fully stable and mature".  Use without backups is 
highly discouraged, but I'd suggest that btrfs in its current state might 
not be what you're looking for if you can't deal with loss of more than 
15 minutes worth of changes anyway.

Be that as it may...

Btrfs is definitely not yet optimized.  In many cases it reads or writes 
only one device at a time, for instance, even in RaidN configuration.  
And there are definitely snapshot scaling issues altho at your newer 500 
snapshots total that shouldn't be /too/ bad.

Dealing with reality, regardless of how or why, you currently have a 
situation of intolerably slow receives that needs addressed.  From a 
practical perspective you said an ssd for backups is ridiculous and I 
can't disagree, but there's another "throw hardware at it" solution that 
might be a bit more reasonable...

Spinning rust hard drives are cheap.  What about getting another one, and 
alternating your backup receives between them?  That would halve the load 
to one every thirty minutes, without changing your 15-minute snapshot and 
backup policy at all. =:^)

So that gives you two choices for halving the load to the spinning rust.  
Either decide you really can live with half-hour loss of data, or throw 
only a relatively small amount of money (well, as long as you have room 
to plug in another sata device anyway, otherwise...) at it for a second 
backup device, and alternate between them.


OTOH, since you mentioned possible coding, optimization might not be a 
bad thing, if you're willing to put in the time necessary to get up to 
speed with the code and can work with the other devs in terms of timing, 
etc.  But that will definitely take significant time even if you do it, 
and the alternating backup solution can be put to use as soon as you can 
get another device plugged in and setup. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


  parent reply	other threads:[~2016-03-17  7:00 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-22 19:58 Major HDD performance degradation on btrfs receive Nazar Mokrynskyi
2016-02-22 23:30 ` Duncan
2016-02-23 17:26   ` Marc MERLIN
2016-02-23 17:34     ` Marc MERLIN
2016-02-23 18:01       ` Lionel Bouton
2016-02-23 18:30         ` Marc MERLIN
2016-02-23 20:35           ` Lionel Bouton
2016-02-24 10:01     ` Patrik Lundquist
2016-02-23 16:55 ` Nazar Mokrynskyi
2016-02-23 17:05   ` Alexander Fougner
2016-02-23 17:18     ` Nazar Mokrynskyi
2016-02-23 17:29       ` Alexander Fougner
2016-02-23 17:34         ` Nazar Mokrynskyi
2016-02-23 18:09           ` Austin S. Hemmelgarn
2016-02-23 17:44 ` Nazar Mokrynskyi
2016-02-24 22:32   ` Henk Slager
2016-02-24 22:46     ` Nazar Mokrynskyi
     [not found]     ` <ce805cd7-422c-ab6a-fbf8-18a304aa640d@mokrynskyi.com>
2016-02-25  1:04       ` Henk Slager
2016-03-15  0:47         ` Nazar Mokrynskyi
2016-03-15 23:11           ` Henk Slager
2016-03-16  3:37             ` Nazar Mokrynskyi
2016-03-16  4:18               ` Chris Murphy
2016-03-16  4:23                 ` Nazar Mokrynskyi
2016-03-16  6:51                   ` Chris Murphy
2016-03-16 11:53                     ` Austin S. Hemmelgarn
2016-03-16 20:58                       ` Chris Murphy
2016-03-16  4:22               ` Chris Murphy
2016-03-17  7:00               ` Duncan [this message]
2016-03-18 14:22                 ` Nazar Mokrynskyi
2016-05-27  1:57                   ` Nazar Mokrynskyi
  -- strict thread matches above, loose matches on Subject: below --
2016-02-22 19:39 Nazar Mokrynskyi
2016-02-16  4:44 Nazar Mokrynskyi
2016-02-16  9:10 ` Duncan
2016-02-18 18:19 ` Henk Slager

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='pan$993a$3e6653ed$790f69a1$c396ece4@cox.net' \
    --to=1i5t5.duncan@cox.net \
    --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;
as well as URLs for NNTP newsgroup(s).