partitions through device-mapper
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
Quoted 23 lines · 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 / structsAlong 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
Quoted 7 lines
This tool cannot damage your data :
BLKPG_DEL_PARTITIONandBLKPG_ADD_PARTITIONioctls 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.
Quoted 2 lines
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)
Quoted 8 lines
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)
Quoted 13 lines · christophe varoqui
Quoted 2 lines
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)
Quoted 7 lines
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]
Quoted 7 lines
Quoted 1 line
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