On Fri, 2011-04-15 at 13:09 -0500, Anthony Liguori wrote: > On 04/15/2011 11:23 AM, Badari Pulavarty wrote: > > On Fri, 2011-04-15 at 17:34 +0200, Christoph Hellwig wrote: > >> On Fri, Apr 15, 2011 at 04:26:41PM +0100, Stefan Hajnoczi wrote: > >>> On Fri, Apr 15, 2011 at 4:05 PM, Christoph Hellwig<h...@lst.de> wrote: > >>>> NAK. ?Just wait for the bloody NFS client fix to get in instead of > >>>> adding crap like that. > >>> That's totally fine if NFS client will be fixed in the near future but > >>> this doesn't seem likely: > >>> > >>> http://www.spinics.net/lists/linux-nfs/msg20462.html > >> The code to use preadv/pwritev has been in qemu for over 2 years, > >> and it took people to notice the NFS slowdown until now, so don't > >> expect it to be fixed three days layer. > > True. That brings up a different question - whether we are doing > > enough testing on mainline QEMU :( > > The issue here is NFS, not QEMU.
Sure. But we should have caught the regression on NFS when preadv/pwritev change went into QEMU or before going in -- Isn't it ? Since it was 2 years ago (like hch indicated) - we could have fixed NFS long ago :) > Moreover, the real problem is that > we're using O_DIRECT. O_DIRECT seems to result in nothing but problems > and it never seems to be tested well on any file system. O_DIRECT was added for a specific use-case in mind - and its supposed to handle only that case well (pre-allocated files with database usage - where db has their own caching layer). That case is well tested by various DB vendors on most (important) local filesystems. You know very well why we are on O_DIRECT path :) > > I think the fundamental problem we keep running into really boils down > to O_DIRECT being a second class interface within Linux. Its by design. Its a special case for specific use. Thanks, Badari