On 03/21/2011 02:00 PM, Hilko Bengen wrote: > Please consider the following scenario consisting of two servers, "A" > and "B", with interfaces to a common Ethernet broadcast domain "x". "B" > additionally has an interface in a separate broadcast domain "y" that is > shared with other machines. "A" provides a target (shelf=0, slot=0) to > "B" over "x" while "B" provides a target (also shelf=0, slot=0) via "y".
ok, i do see how this might cause a problem.
> You might argue that the scenario I am describing isn't exactly good
> practice and I might agree. But provided that the initiator and target
> on "B" are configured to not use the same ethernet device, there are no
> reasons imposed by the AoE protocol why this should not work.
The same scenario without vblade-persist has a comparable race condition
on "A" if machine "C" (attached to "y") provides a target (shelf=1,
slot=1) and "B" (attached to "x") concurrently provides a target
(shelf=1, slot=1). How does the kernel + udev decide what to treat as
/dev/etherd/e1.1 in that case?
I'm not convinced that removing vblade-persist's symlinks will fix the
race condition for this "not exactly good practice" scenario.
Is there a reasonable scenario (one that doesn't have its own race
conditions already) that this symlink introduces problems for?
> I think I see what you are trying to do there. However, the kernel-based
> AoE initiator will also ask udev to create device nodes corresponding to
> partitions on the device (e0.0p1), so creating the symlink for the wohle
> device isn't even enough to create the consistent view.
Ah, this is also a good point -- i hadn't realized that the kernel would
do that, because it never occurred to me that anyone would want to use
crufty old partition tables on their AoE devices. And i suppose using
kpartx on the symlink wouldn't really be sufficient, since the
supporting file might not itself actually be a block device, and i don't
think kpartx works on non-block-special files.
Do you have a suggestion for how we might solve the node-independent
view of /dev/etherd/ that this symlink approach was originally trying to
address?
Should aoetools create them on its own?
Thanks for the discussion,
--dkg
signature.asc
Description: OpenPGP digital signature
