On Fri, Dec 12, 2008 at 08:35:57AM -0600, Anthony Liguori wrote: > I've been thinking about this, the problems I see are: > > 1) It's impossible to accept a file descriptor for a block device (possibly > not a problem)
What do you mean with accept? You mean to accept a tcp connection? How would a block device fd be related to accept(2)? > 2) You'd have to open all the file descriptors at once. Otherwise, you get > really strange behavior if the file gets deleted while the guest is running > (for instance, with -snapshot). Definitely, that's what I meant with hack around the bdrv api... not even close to nice but doable in theory. Only advantage is that it runs on older kernels but with seeking I/O lseek has to run as well. Now that linux-aio is out of the picture for quite a long time for us, I guess it worth to wait preadv/pwritev and stick with that and reconsider linux-aio after they fix it... Waiting Gerd to post a full patch. But it's your call... I'm fine either ways. Clearly the os missing preadv/pwritev would need to be limited to 1 thread per fd (but 1 thread per fd kind of breaks with the current _global_ list so I guess they'll be limited to just 1 thread otherwise it may be actually simpler to just open the file multiple times than to have a per-fd queue ;), not the end of the world for them. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html