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
On Tue, 29 Oct 2002 [email protected] 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.
> 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)
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