Re: [Qemu-devel] migration question: disk images on nfs server

[Orit Wasserman]

On 02/07/2014 02:54 PM, Marcin Gibuła wrote:
> > It is more a NFS issue, if you have a file in NFS that two users in
> > two different host are accessing (one at least write to it) you will
> > need to enforce the "sync" option.
> > Even if you flush all the data and close the file the NFS client can still
> > have cached data that it didn't sync to the server.
>
> Do you know if is applies to linux O_DIRECT writes as well?

From the man of open:

       The behaviour of O_DIRECT with NFS will differ from local
       filesystems.  Older kernels, or kernels configured in certain ways,
       may not support this combination.  The NFS protocol does not support
       passing the flag to the server, so O_DIRECT I/O will bypass the page
       cache only on the client; the server may still cache the I/O.  The
       client asks the server to make the I/O synchronous to preserve the
       synchronous semantics of O_DIRECT.  Some servers will perform poorly
       under these circumstances, especially if the I/O size is small.  Some
       servers may also be configured to lie to clients about the I/O having
       reached stable storage; this will avoid the performance penalty at
       some risk to data integrity in the event of server power failure.
       The Linux NFS client places no alignment restrictions on O_DIRECT
       I/O.
 
To summaries it depends on your kernel (NFS client).


>  From comment in fs/nfs/direct.c:
>
> * When an application requests uncached I/O, all read and write requests
> * are made directly to the server; data stored or fetched via these
> * requests is not cached in the Linux page cache.  The client does not
> * correct unaligned requests from applications.  All requested bytes are
> * held on permanent storage before a direct write system call returns to
> * an application.

>