On 03/21/2011 07:12 PM, Hilko Bengen wrote: > (1) A shelf/slot address should uniquely identify a target in a > broadcast domain. > > (2) A shelf/slot address should uniquely identify a target reachable > from a host via any network interface that is configured for AoE. (Your > example above violates this.) > > If I can't guarantee both, I risk data loss.
Yes, exactly. And the concern you've reported here about vblade-persist
will *only* be triggered in the case where at least one of these two is
violated.
I'm still looking for the use case where vblade-persist's symlink
creation is actually independently problematic.
> As the node-independent consistent view seems to be important to you:
> Could you live with putting the symlinks into a different directory
> (e.g. /var/run/vblade-persist as suggested) and extend the udev rules to
> create symlinks to any real /dev/etherd/ex.y device node that may pop
> up? (I would make the last part optional and off-by-default, though.)
This seems excessive to me -- the standard place for these files is
/dev/etherd. Even without a concrete example of a situation were the
symlinks cause a problem, I would happily consider a patch to add an
option to vblade-persist to have it avoid creating a symlink for any
given vblade export.
If you can help me understand an example with a reasonable configuration
where this symlink actually causes a problem, i could even write the
patch myself :)
But i don't think i see the problem yet under any reasonable AoE setup.
> Why is the node-independent view so important to you, anyeay? What
> problem does it solve?
OK, here's an example: consider a group of machines, each providing
physical storage to a pool on a shared network segment, and each acting
as a host for some common virtualization implementation (e.g. KVM).
Each virtual server (guest) has a set of configuration information that
tells it where to pull its disks from.
It would be good to be able to migrate guests from one host to another
without needing to tweak the guest's configuration. A node-independent
view of the AoE domain is quite useful in this situation -- i can say
"guest X has /dev/etherd/e4.3 as a virtual block device" and not have to
worry about whether guest X happens to be running on the host
responsible for exporting (shelf=4,slot=3).
Thanks for raising the issue and talking this over with me.
Regards,
--dkg
signature.asc
Description: OpenPGP digital signature
