* [RFC]partitions through device-mapper
@ 2002-10-29 13:39 christophe.varoqui
2002-10-29 14:22 ` Alexander Viro
0 siblings, 1 reply; 4+ messages in thread
From: christophe.varoqui @ 2002-10-29 13:39 UTC (permalink / raw)
To: linux-kernel
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [RFC]partitions through device-mapper
2002-10-29 13:39 [RFC]partitions through device-mapper christophe.varoqui
@ 2002-10-29 14:22 ` Alexander Viro
2002-10-29 18:41 ` christophe varoqui
0 siblings, 1 reply; 4+ messages in thread
From: Alexander Viro @ 2002-10-29 14:22 UTC (permalink / raw)
To: christophe.varoqui; +Cc: linux-kernel
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [RFC]partitions through device-mapper
2002-10-29 14:22 ` Alexander Viro
@ 2002-10-29 18:41 ` christophe varoqui
2002-10-29 23:14 ` Greg KH
0 siblings, 1 reply; 4+ messages in thread
From: christophe varoqui @ 2002-10-29 18:41 UTC (permalink / raw)
To: Alexander Viro; +Cc: linux-kernel
> 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)
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [RFC]partitions through device-mapper
2002-10-29 18:41 ` christophe varoqui
@ 2002-10-29 23:14 ` Greg KH
0 siblings, 0 replies; 4+ messages in thread
From: Greg KH @ 2002-10-29 23:14 UTC (permalink / raw)
To: christophe varoqui; +Cc: linux-kernel
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2002-10-29 23:10 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-10-29 13:39 [RFC]partitions through device-mapper christophe.varoqui
2002-10-29 14:22 ` Alexander Viro
2002-10-29 18:41 ` christophe varoqui
2002-10-29 23:14 ` Greg KH
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).