From: Tejun Heo <tj@kernel.org>
To: Jens Axboe <jens.axboe@oracle.com>
Cc: Nikanth Karthikesan <knikanth@suse.de>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] [RFC] make hd_struct->in_flight atomic to avoid diskstat corruption
Date: Sun, 19 Apr 2009 17:51:14 +0900 [thread overview]
Message-ID: <49EAE602.3090802@kernel.org> (raw)
In-Reply-To: <20090416163254.GQ5178@kernel.dk>
Hello,
Jens Axboe wrote:
> On Thu, Apr 16 2009, Tejun Heo wrote:
>> Hello, Nikanth, Jens.
>>
>> Nikanth Karthikesan wrote:
>>>> Hmm. Did you observe this behaviour?
>>> Sorry, not on current kernels. But on a very old 2.6.5 kernel.
>>>
>>> Reading Documentation/iostats.txt and the changelog of commit
>>> e71bf0d0ee89e51b92776391c5634938236977d5 made me assume that this could be a
>>> problem even today.
>> The only problem we can run into there is if a request doesn't get
>> attributed to a partition on issue but gets attributed to a partition
>> on completion, which seems to be possible if a new partition is added
>> while IO on the whole device which fell into the new partition area is
>> already in progress, which, on the first glance, seems possible if the
>> admin tries really hard. I think we can get around the problem by
>> doing part->in_flight = min(max(new_val, part0->in_flight), 0) in
>> dec_in_flight(). This is pretty extreme corner case tho.
>
> Heh, that is pretty extreme. I'd prefer just quiescing the queue,
> perhaps we should do that for partition map swaps.
Yeah, I think that would be the better approach for swapping ptbl.
RCU isn't really necessary there.
Thanks.
--
tejun
next prev parent reply other threads:[~2009-04-19 8:52 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-16 7:24 [PATCH] [RFC] make hd_struct->in_flight atomic to avoid diskstat corruption Nikanth Karthikesan
2009-04-16 7:35 ` Jens Axboe
2009-04-16 9:15 ` Nikanth Karthikesan
2009-04-16 14:40 ` Tejun Heo
2009-04-16 16:32 ` Jens Axboe
2009-04-19 8:51 ` Tejun Heo [this message]
2009-04-21 7:31 ` Jens Axboe
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=49EAE602.3090802@kernel.org \
--to=tj@kernel.org \
--cc=jens.axboe@oracle.com \
--cc=knikanth@suse.de \
--cc=linux-kernel@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.