* Daniel Kahn Gillmor: > Thanks for the report! > > I don't think this is a problem, because aoetools doesn't seem to > trigger for aoe devices on the local machine's network interface. If > you know otherwise, i'd be happy to hear of a specific configuration > where this is the case.
My point is that /dev/etherd belongs to the Linux kernel-based AoE _initiator_ and that a user-space based AoE _target_ has no business manipulating this directory. 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". If the target on "B" is managed using vblade-persist I see two possible failure modes: 1. If the initiator finds its target on "A" before vblade-persist is started, "B" won't export a target via "y" because vblade-persist can't create the desired symlink. 2. If the initiator finds its target on "A" after vblade-persist has been started, udev will try to create a device node (as instructed by the kernel) where vblade-persist has put its symlink. I haven't tried this, so I don't know whether udev would succeed in creating this device node. I'd call this a race condition. 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 links are created there by vblade-persist precisely so that a > machine can both offer and consume AoE, while seeing what its other > peers see. 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. Cheers, -Hilko -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
