[RFC]partitions through device-mapper

[RFC]partitions through device-mapper

[christophe.varoqui]

Hello, 
 
now that the device mapper is merged into mainline, I would like to open a 
discussion on the possible in-kernel partition handling clean-up. 
 
In-kernel partition handling covers : 
o parsing of the on-disk partition tables 
o partition block devices creation / structs 
 
Along with initramfs will come the possibility to rip off the partition tables 
parsing from the kernel : a userspace parser like partx (part of util-linux 
toolset) can teach the kernel the partition layout. 
 
As driverfs provides elegantly block device add/remove events to hotplug, calls 
to partx can be wrapped into the block.agent 
 
The device-mapper merging could enable the ripping of all kernel partition 
understanding by creating linear device-maps over partitions. 
 
As a proof of concept, I've mutated partx to create those mappings. This tool 
is available for testing and commenting at : 
http://dsit.free.fr/dmpartx.tar.bz2 
 
This tool cannot damage your data : BLKPG_DEL_PARTITION and  
BLKPG_ADD_PARTITION ioctls are removed from the source. 
 
I would like to receive feedback over the following points : 
 
* Is this proposal completely out of the point ? Have I overlooked some 
important implementation details ? 
 
* driverfs send block device-removal-event at the end of the job, but device 
removal cannot happen as there are device-mappings over it. This ordering 
forbids hotplug to trigger the partition-mappings flush before block-device 
removal. Can this ordering be changed, or is there another solution ? 
 
* 2.5.44-ac4 did not notify block-device-add upon scsi disk insertion with 
scsi-add-single-device, which I think is known by scsi subsystem maintainers. 
-> The block.agent provided with dmpartx is not tested. 
 
* Should dmpartx create the 0-lengh partitions ? It does not at the moment. 
Extended partitions are handled the same way as partx : resize to 63 blocks 
 
 
regards, 
cvaroqui 

Re: [RFC]partitions through device-mapper

[Alexander Viro]

On Tue, 29 Oct 2002 christophe.varoqui@free.fr wrote:

> Hello, 
>  
> now that the device mapper is merged into mainline, I would like to open a 
> discussion on the possible in-kernel partition handling clean-up. 
>  
> In-kernel partition handling covers : 
> o parsing of the on-disk partition tables 
> o partition block devices creation / structs 
>  
> Along with initramfs will come the possibility to rip off the partition tables 
> parsing from the kernel : a userspace parser like partx (part of util-linux 
> toolset) can teach the kernel the partition layout. 
>  
> As driverfs provides elegantly block device add/remove events to hotplug, calls 
> to partx can be wrapped into the block.agent 
>  
> The device-mapper merging could enable the ripping of all kernel partition 
> understanding by creating linear device-maps over partitions. 
>  
> As a proof of concept, I've mutated partx to create those mappings. This tool 
> is available for testing and commenting at : 
> http://dsit.free.fr/dmpartx.tar.bz2 
>  
> This tool cannot damage your data : BLKPG_DEL_PARTITION and  
> BLKPG_ADD_PARTITION ioctls are removed from the source. 
>  
> I would like to receive feedback over the following points : 
>  
> * Is this proposal completely out of the point ? Have I overlooked some 
> important implementation details ? 

a) devmapper is merged, but it sure as hell is not mandatory

b) relying on the hotplug working right means living dangerously.  Right
now that code is brittle in the best case.

c) all existing races in overlapping attach/detach (and $DEITY witness,
there's a plenty) immediately become much wider [OK, that's part of
(b), actully]

IOW, right now the thing is nowhere near being ready for such use.

Re: [RFC]partitions through device-mapper

[christophe varoqui]

> a) devmapper is merged, but it sure as hell is not mandatory
>
let me argue that if I decide to hand my system FS to the device-mapper I 
wouldn't want the current partition code to be mandatory either (devil's 
advocate speaking)

> b) relying on the hotplug working right means living dangerously.  Right
> now that code is brittle in the best case.
>
> c) all existing races in overlapping attach/detach (and $DEITY witness,
> there's a plenty) immediately become much wider [OK, that's part of
> (b), actully]
>
> IOW, right now the thing is nowhere near being ready for such use.

point taken.
But, the question remains : do we want to get there in the end ?
(question from the time-and-effort-worthy? departement)

Re: [RFC]partitions through device-mapper

[Greg KH]

On Tue, Oct 29, 2002 at 08:41:10PM +0200, christophe varoqui wrote:
> > a) devmapper is merged, but it sure as hell is not mandatory
> >
> let me argue that if I decide to hand my system FS to the device-mapper I 
> wouldn't want the current partition code to be mandatory either (devil's 
> advocate speaking)
> 
> > b) relying on the hotplug working right means living dangerously.  Right
> > now that code is brittle in the best case.
> >
> > c) all existing races in overlapping attach/detach (and $DEITY witness,
> > there's a plenty) immediately become much wider [OK, that's part of
> > (b), actully]
> >
> > IOW, right now the thing is nowhere near being ready for such use.
> 
> point taken.
> But, the question remains : do we want to get there in the end ?
> (question from the time-and-effort-worthy? departement)

>From what I understand about partitions, yes, I think we eventually do
want to get there.  

thanks,

greg k-h