* Daniel Kahn Gillmor: > 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?
This is outright dangerous: Unless you have configured the AoE initiator on host "A" is restrict itself to access (interfaces on) only one broadcast domain, there is no way of predicting which device will be read or modified. In my book, this is random data corruption. Like many other technologies, AoE will happily allow us to shoot ourselves in the foot. :-) The downside of a standard as simple as <http://support.coraid.com/documents/AoEr11.txt> is that we have to work with a few assumptions. Mine so far are: (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. > 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? 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.) Why is the node-independent view so important to you, anyeay? What problem does it solve? Cheers, -Hilko -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
