linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Behrens <sbehrens@giantdisaster.de>
To: TM <tmjuju@yahoo.com>, linux-btrfs@vger.kernel.org
Subject: Re: 1 week to rebuid 4x 3TB raid10 is a long time!
Date: Tue, 22 Jul 2014 17:30:28 +0200	[thread overview]
Message-ID: <53CE8394.9010903@giantdisaster.de> (raw)
In-Reply-To: <loom.20140722T164042-111@post.gmane.org>

On Tue, 22 Jul 2014 14:43:45 +0000 (UTC), Tm wrote:
> Wang Shilong <wangsl.fnst <at> cn.fujitsu.com> writes:
> 
> 
>> The latest btrfs-progs include man page of btrfs-replace. Actually, you 
>> could use it
>> something like:
>>
>> btrfs replace start  <srcdev>|<devid> <targetdev> <mnt>
>>
>> You could use 'btrfs file show' to see missing device id. and then run 
>> btrfs replace.
>>
> 
> Hi Wang,
> 
>   I physically removed the drive before the rebuild, having a failing device
> as a source is not a good idea anyway.
>   Without the device in place, the device name is not showing up, since the
> missing device is not under /dev/sdXX or anything else. 
> 
>   That is why I asked if the special parameter 'missing' may be used in a
> replace. I can't say if it is supported. But I guess not, since I found no
> documentation on this matter.
> 
>   So I guess replace is not aimed at fault tolerance / rebuilding. It's just
> a convenient way to lets lay replace the disks with larger disks , to extend
> your array. A convenience tool, not an emergency tool.

TM, Just read the man-page. You could have used the replace tool after
physically removing the failing device.

Quoting the man page:
"If the source device is not available anymore, or if the -r option is
set, the data is built only using the RAID redundancy mechanisms.

Options
-r   only read from <srcdev> if no other zero-defect mirror
     exists (enable this if your drive has lots of read errors,
     the access would be very slow)"


Concerning the rebuild performance, the access to the disk is linear for
both reading and writing, I measured above 75 MByte/s at that time with
regular 7200 RPM disks, which would be less than 10 hours to replace a
3TB disk (in worst case, if it is completely filled up).
Unused/unallocated areas are skipped and additionally improve the
rebuild speed.

For missing disks, unfortunately the command invocation is not using the
term "missing" but the numerical device-id instead of the device name.
"missing" _is_ implemented in the kernel part of the replace code, but
was simply forgotten in the user mode part, at least it was forgotten in
the man page.



  reply	other threads:[~2014-07-22 15:30 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-20  8:45 1 week to rebuid 4x 3TB raid10 is a long time! TM
2014-07-20 13:53 ` Duncan
2014-07-20 14:00   ` Tomasz Torcz
2014-07-20 14:50     ` Austin S Hemmelgarn
2014-07-20 17:15     ` ashford
2014-07-20 18:21       ` TM
2014-07-20 18:23       ` TM
2014-07-20 19:15 ` Bob Marley
2014-07-20 19:36   ` Roman Mamedov
2014-07-20 19:59     ` ashford
2014-07-21  2:48       ` Duncan
2014-07-21 16:46         ` ronnie sahlberg
2014-07-21 18:31           ` Chris Murphy
2014-07-22  2:51           ` Duncan
2014-07-22 17:13             ` Chris Murphy
2014-07-24 17:19               ` Chris Murphy
2014-07-20 21:28     ` Bob Marley
2014-07-20 21:54       ` George Mitchell
2014-07-21  1:22 ` Wang Shilong
2014-07-21 14:00   ` TM
2014-07-22  1:10     ` Wang Shilong
2014-07-22  1:17     ` Wang Shilong
2014-07-22 14:43       ` TM
2014-07-22 15:30         ` Stefan Behrens [this message]
2014-07-22 20:21           ` TM

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=53CE8394.9010903@giantdisaster.de \
    --to=sbehrens@giantdisaster.de \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=tmjuju@yahoo.com \
    /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).