All of lore.kernel.org
 help / color / mirror / Atom feed
From: George Mitchell <george@chinilu.com>
To: Martin Steigerwald <Martin@lichtvoll.de>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Scrub CPU usage ...
Date: Sun, 05 May 2013 07:15:48 -0700	[thread overview]
Message-ID: <51866994.8010107@chinilu.com> (raw)
In-Reply-To: <2221106.SQ983GtkxQ@merkaba>


On 05/05/2013 02:22 AM, Martin Steigerwald wrote:
> Hi George!
>
> Am Samstag, 4. Mai 2013, 11:39:59 schrieb George Mitchell:
>> the next update.  I am using btrfs raid 1 across five 500GB Seagate
>> nearline drives and btrfs single on a Seagate 4TB backup drive.  I am
>> absolutely delighted with how this system is working.  This is my
>> primary day in and day out system.  I have to date hard crashed this
>> system at least three times without sustaining any apparent damage to
>> the filesystems.  Perhaps I have just been extremely lucky, but it seems
>> like most of the major holes have been closed at this point.  Actually I
>> have only two significant issues currently with btrfs.
> Are you aware that BTRFS RAID-1 works differently than block based RAID? BTRFS
> will only be holding two copies of every data or metadata chunk on two
> different drives, regardless how many drives you use. So only one drive may
> fail.
>
> Well, I think you will have notices with df output for the filesystem, but I
> thought I mention it, just in case.
>
> Thanks,
Yes indeed!  I was aware of this from the beginning.  All I am looking 
for is duplication across hardware.  The advantage of more than two 
drives is that in case you lose a drive, you don't end up losing a lot 
of space, and you are much less likely to end up in an unduplicated 
state for a significant amount of time.  But thanks for your thoughts!  
What I am NOT missing about the old 3ware card is the resyncs.  I used 
to spend half a day doing drive resyncs when a drive dropped out for 
some reason.  Hardware RAID is great when it works, but I much prefer 
btrfs.  Software RAID has its own problems.  Its gotten better I hear, 
but when I used it for a long time, I was a pain.  But both forms of 
block RAID saved me from ever losing data.  - George

      reply	other threads:[~2013-05-05 14:15 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-04 18:39 Scrub CPU usage George Mitchell
2013-05-05  1:21 ` Kai Krakow
2013-05-05  1:58   ` George Mitchell
2013-05-05  9:22 ` Martin Steigerwald
2013-05-05 14:15   ` George Mitchell [this message]

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=51866994.8010107@chinilu.com \
    --to=george@chinilu.com \
    --cc=Martin@lichtvoll.de \
    --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.