On Wed, Mar 05, 2014 at 03:20:55PM -0500, Paul Clements wrote: > Although I wonder how bad the current situation really is.
The losetup --find --show being racy kind of stumped me, I'm not sure if this issue is known at all, Google doesn't give me anything except this: http://www.spinics.net/lists/util-linux-ng/msg00221.html It seems the --show was added in the first place to avoid race, yet it suffers from one; (for i in {1..100}; do losetup -f -s $i & done) does not give you a hundred loop devices... instead it keeps reusing already used ones. If nobody notices such an issue in years it's probably not relevant in practice... > Are people having difficulties with races and such in trying to > allocate nbds? I guess the race is a problem of a very theoretical nature only... two processes trying to find a nbd device at the same millisecond is just extremely unlikely. Finding a free nbd device still seems a bit of a challenge to me. Although that may be because my buggy program is leaving behind nbd devices in a bad state, so they're still listed in /proc/partitions even though there is no process using them anymore, and even nbd-client -d does not get rid of them. The /sys/block/nbd*/pid seems to be the safest way to check, and never mind the race conditions... Regards Andreas Klauer ------------------------------------------------------------------------------ Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk _______________________________________________ Nbd-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/nbd-general
