Hello Guan,
On Fri, 2017-07-21 at 13:07 +0800, Guan Junxiong wrote:
> This three patches support coalescing heterogenous paths by
> referencing
> another path identifier. This is useful in the scenario of migrating
> data
> for heterogenous arrays without interrupting uplayer transaction.
Maybe I'm completely misunderstanding the intention of your patch, but
from what I gathered I think this is a is a *very dangerous thing* to
begin with.
Can you please explain "migrating data for heterogeneous arrays" in
more detail. What exactly is happening here? What does the admin do, in
what order? What's happening on the storage side?
Say you have two different disks sda and sdd, and you use
> uid_reference "sd[a-c] sdd"
With your patch applied, these devices show up with different WWIDs in
the system, but multipathd pretends that sda has the same WWID as sdd
and coalesces the two into one map.
Under normal conditions, this would inevitably cause data corruption,
unless the disks are really actually the same (but if that's the case,
why do they show different WWIDs?), or some entity (the storage array?)
mirrors the data between the disks behind the scenes.
I'd like to understand what's going on and how you are prevent data
corruption in this scenario.
Am I understanding correctly that this would be a temporary situation
during some sort of data migration procedure? If yes, what happens
after the migration is finished? If this is actually a transient
condition, I don't think using multipath.conf for this is a good idea.
Multipath.conf is normally used to store persistent system state.
Suppose someone adds a uid_reference to multipath conf, migrates data,
and forgets to remove the uid_reference from multipath.conf (and
restart multipathd) afterwards. If disks are added later, and
multipathd uses the uid_reference mapping for two unrelated disks, data
corruption will occur. *This is dangerous*. It'd be safer if you'd use
mapping by WWID ("pretend that WWID x is actually WWID y") rather than
mapping by device name.
Maybe I'm missing something important here, therefore I'm asking for
more explanation.
Anyway, I'm wondering if multipath configuration is the right place to
apply a "fake" configuration like this. Have you considered doing this
on the udev level? Udev has the advantage that udev immediately sees
added or modified rules files. So if you want to pretend temporarily
that sda is indeed the same disk as sdd, you could insert appropriate
temporary udev rules to do that. This would have the additional benefit
that not only multipathd sees the mangled WWID but also the rest of the
system (IOW, multipathd's view of the system would be consistent with
the world outside multipathd).
Postponing a detailed technical patch review until these questions are
clarified.
Regards,
Martin
--
Dr. Martin Wilck <mwilck@xxxxxxxx>, Tel. +49 (0)911 74053 2107
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
