[lkml]   [2012]   [Jan]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 1/2] Add partition resize function to BLKPG ioctl
Hash: SHA1

On 1/26/2012 2:01 PM, Vivek Goyal wrote:
> I thought update will always happen with mutex lock held. That's
> what sequence counter expects so that two updaters don't race. Just
> that while updating under mutex lock, we still need to use sequence
> counter mecahinsm to update values so that any readers out there
> not holding mutex don't get confused.

Yes, but holding the mutex while writing does no good for the reader.
When the writer doesn't use the seqcounter, then the reader that is
using it is not actually protected.

> Right now readers can afford not to take lock. Introducing mutex on
> read side with just add to the cost. Especially IO submission path
> where we map IO to a partitiona and we wouldn't want to take
> mutexes there?

Yes, it does look like readers can't afford that overhead.

> Are you still pursuing this pathset? Sounds like a useful
> functionality to have.

Yes, but I hadn't yet heard back about my question about this being a
broader issue that is already a bug in the kernel because things like
loop and md already change nr_sects ( on the whole disk partition )
without any protection.

Maybe what we need is a read/write lock on struct genhd, then all
readers need to acquire the read lock, which should only slow them
down if they collide with a writer.

Another idea that I had but have not yet checked to see if it is
actually feasible is to copy the struct genhd, change the size of the
copy, and replace the existing one since updating the pointer will be
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Mozilla -


 \ /
  Last update: 2012-01-26 21:37    [W:0.134 / U:0.480 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site