On 03/12/2014 03:43 PM, Peter Rajnoha wrote:
On 03/12/2014 02:14 PM, Hannes Reinecke wrote:
_However_: The 'no_partition' feature has the advantage that you
don't need to modify the multipath code; it'll just take whatever is
in 'features' and pass it 1:1 into the device-mapper table.
But you still need some config file in userspace that will store
the fact that some of the mpath devs need to be marked with this
feature flag.
Yes. Multipath already has the 'multipath.conf' file, which is
used to specify and/or modify multipath devices.
Including the ability to set the 'features' string,
which is passed 1:1 into the device-mapper core.
When using cookies for that we'd need either a separate
mechanism/flag for multipathing or filter out the features list.
_And_ we need to modify libdevmapper _and_ multipath at the same
time to make that work.
But if you insist ...
If this is a subsystem specific (in this case mpath) flag, we
don't need to change libdevmapper, only mpath userspace code.
Ah. Ok, that simplifies matters.
So can you make a patch for libdevmapper to add this cookie flag?
I'll be checking the multipath-tools code ...
I'll try to think about this a bit more since it would be beneficial
to have such a thing for all block devices actually - any of them
can be be used in a VM and we need to prevent scanning all such
devices, not just mpath ones. A simple solution would be for users
to define a udev rule (providing them a template) where they can
match against some properties (e.g. DM name, uuid or WWID or whatever
else is present for the block dev to match against in the rule).
This actually brings us to a general problem with making the device
"private" in some way on the host system. AFAIK we still don't have
a general rule for this! Everybody is patching this on his own.
With all the support for various autoactivations and automounts,
this can become quite dangerous then if not configured properly
by each subsystem's mechanism to make the device private.
Hehe. I've got a patch which implements a 'no_partition_scan' kernel
parameter, disabling the in-kernel partition scanning code altogether.
Especially useful if you're running on a root-on-multipath system,
as then basically _all_ devices are handled by multipathing, so
the in-kernel partition scan is pointless at best.
At worst it'll trigger tons of I/O errors on the passive path,
slowing down the machine to an eventual halt as the serial console
overflows.
And, btw, a udev rule won't work as the in-kernel scanning code
would be called nevertheless. You'd need to inhibit that, only then can
you intercept the scanning.
I can post it here if you're interested ...
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@xxxxxxx +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
