From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: how long should "btrfs device delete missing ..." take?
Date: Thu, 11 Sep 2014 23:51:26 +0000 (UTC) [thread overview]
Message-ID: <pan$a2cc2$dc8ad02$d35780a0$4fefc791@cox.net> (raw)
In-Reply-To: 4A9B52AD-8104-4C31-9BA4-13D329D2F952@colorremedies.com
Chris Murphy posted on Thu, 11 Sep 2014 15:25:51 -0600 as excerpted:
> On Sep 11, 2014, at 1:31 PM, Duncan <1i5t5.duncan@cox.net> wrote:
>>
>> I wouldn't try defragging now, but it might be worthwhile to stop the
>> device delete (rebooting to do so since I don't think there's a cancel)
>
> 'btrfs replace cancel' does exist, although I haven't tried it.
Btrfs replace cancel exists, yes, but does it work for btrfs device
delete, which is what the OP used?
> Something isn't right though, because it's clearly neither reading nor
> writing at anywhere close to 1/2 the drive read throughput. I'm curious
> what 'iotop -d30 -o' shows (during the replace, before cancel), which
> should be pretty consistent by averaging 30 seconds worth of io. And
> then try 'iotop -d3 -o' and see if there are spikes. I'm willing to bet
> there's a lot of nothing going on, with occasional spikes, rather than a
> constant trickle.
>
> And then the question is to find out what btrfs is thinking about while
> nothing is reading or writing. Even though it's not 5000+ snapshots, I
> wonder if the balance code (and hence btrfs replace) makes extensive use
> of fiemap that's causing this to go catatonic.
> http://comments.gmane.org/gmane.comp.file-systems.btrfs/35724
Not sure (some of that stuff's beyond me), but one thing we /do/ know is
that btrfs has so far been focused mostly on features and debugging, not
on optimization beyond the worst-cases, which themselves remain a big
enough problem, tho it's slowly getting better.
--
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
next prev parent reply other threads:[~2014-09-11 23:51 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-11 15:22 how long should "btrfs device delete missing ..." take? Tomasz Chmielewski
2014-09-11 19:31 ` Duncan
2014-09-11 21:25 ` Chris Murphy
2014-09-11 23:51 ` Duncan [this message]
2014-09-12 2:10 ` Chris Murphy
2014-09-12 5:19 ` Russell Coker
2014-09-12 5:33 ` Duncan
2014-09-12 6:27 ` Chris Murphy
2014-09-12 5:41 ` Duncan
2014-09-12 5:59 ` Duncan
2014-09-11 23:06 ` Tomasz Chmielewski
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$a2cc2$dc8ad02$d35780a0$4fefc791@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).