All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wang Shilong <wangsl.fnst@cn.fujitsu.com>
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 09:10:02 +0800	[thread overview]
Message-ID: <53CDB9EA.4020705@cn.fujitsu.com> (raw)
In-Reply-To: <loom.20140721T155907-291@post.gmane.org>

On 07/21/2014 10:00 PM, TM wrote:
> Wang Shilong <wangsl.fnst <at> cn.fujitsu.com> writes:
>
>> Just my two cents:
>>
>> Since 'btrfs replace' support RADI10, I suppose using replace
>> operation is better than 'device removal and add'.
>>
>> Another Question is related to btrfs snapshot-aware balance.
>> How many snapshots did you have in your system?
>>
>> Of course, During balance/resize/device removal operations,
>> you could still snapshot, but fewer snapshots should speed things up!
>>
>> Anyway 'btrfs replace' is implemented more effective than
>> 'device remova and add'.
>>
>
> Hi Wang,
> just one subvolume, no snaphots or anything else.
>
> device replace: to tell you the truth I have not used it in the past. Most
> of my testing was done 2 years ago. So in this 'kind of production' system I
> did not try it. But if I knew that it was faster, perhaps I could have used
> it. Anyone has statistics for such a replace and the time it takes?
I don't have specific statistics about this. The conclusion come from
implementation differences between replace and 'device removal'.


>
> Also, can replace be used when one device is missing? Cant find
> documentation. eg.
> btrfs replace start missing /dev/sdXX
>
>
> TM
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


  reply	other threads:[~2014-07-22  1:15 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 [this message]
2014-07-22  1:17     ` Wang Shilong
2014-07-22 14:43       ` TM
2014-07-22 15:30         ` Stefan Behrens
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=53CDB9EA.4020705@cn.fujitsu.com \
    --to=wangsl.fnst@cn.fujitsu.com \
    --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 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.