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
>
next prev parent 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.