Re: [PATCH] Allow userspace block device implementation

[Andi Kleen <andi@firstfloor.org>]

On Tue, Jul 28, 2009 at 01:50:56PM -0700, Linus Torvalds wrote:
> 
> 
> On Tue, 28 Jul 2009, Andi Kleen wrote:
> 
> > Kyle Moffett <kyle@moffetthome.net> writes:
> > >
> > >   (1) The ability to rearrange, resize, and restructure
> > > partition-tables on the fly.  The existing "re-read partition tables"
> > > infrastructure does not safely and reasonably handle changes to the
> > > partition-table while partitions are mounted. 
> > 
> > It doesn't today (and I really hate it too), but is there a hard reason it
> > couldn't be fixed to support that properly? 
> 
> If something has a partition open (and it doesn't really even have to be a 
> mounted filesystem, altough that's obviously the most relevant case), how 
> can you reasonably change the partition from underneath it?

Well LVM can do that, why not standard partitions?

e.g. extending should be totally fine. The file system can continue
using the old size until you run the online fs extender tool which
does then the right magic to sync the file system state. I believe
that is how it works on LVM.

Shrinking is more difficult, but giving root enough rope ... 
And we got offline shrinkers at least.

> So I assume 
> you mean that partitions were opened earlier (for a mount) would not be 
> touched.

Also right now you can't change any other partition.

I know part of the problem is that I like using fdisk 
(simply because I think the person who designed parted's user interface
was on something unholy) and apparently it works better
when you use the right ioctls to add/remove partitions
instead of wholesale reread like fdisk.
Perhaps the reread table ioctl can be just fixed.

> It may be that we just have the old check in place ("don't allow 
> re-reading if something has mounted a partition"), and we could just get 
> rid of it. I have not looked. 

Yes I'm sure there's lot of historical baggage here.

> 
> But if you actually meant that re-reading the partition table should 
> _change_ a "struct block_dev" that is in use, then I think that would be a 
> bad idea. At the very least, it should involve a re-mount or something.

LVM already does it afaik.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.