Re: NFS Mount Option 'nofsc'

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2012-02-10 at 19:07 +1100, Harshula wrote:
> On Thu, 2012-02-09 at 15:31 +0000, Myklebust, Trond wrote:
> Thanks. Would it be accurate to say that if there were only either
> streaming writes or (xor) streaming reads to any given file on the NFS
> mount, the application would not need to be rewritten? 

That should normally work.

> Do you see forcedirectio as a sharp object that someone could stab
> themselves with?

Yes. It does lead to some very subtle POSIX violations.

> > > There's another scenario, which we talked about a while back, where the
> > > cached async reads of a slowly growing file (tail) was spitting out
> > > non-exist NULLs to user space. The forcedirectio mount option should
> > > prevent that. Furthermore, the "sync" mount option will not help anymore
> > > because you removed nfs_readpage_sync().
> > 
> > No. See the points about O_APPEND and serialisation of read() and
> > write() above. You may still end up seeing NUL characters (and indeed
> > worse forms of corruption).
> 
> If the NFS client only does cached async reads of a slowly growing file
> (tail), what's the problem? Is nfs_readpage_sync() gone forever, or
> could it be revived?

It wouldn't help at all. The problem is the VM's handling of pages vs
the NFS handling of file size.

The VM basically uses the file size in order to determine how much data
a page contains. If that file size changed between the instance we
finished the READ RPC call, and the instance the VM gets round to
locking the page again, reading the data and then checking the file
size, then the VM may end up copying data beyond the end of that
retrieved by the RPC call.

> -osync also impacts the performance of the entire NFS mount. With
> aforementioned hack, you can isolate the specific file(s) that need
> their dirty pages to be flushed frequently to avoid hitting global dirty
> page limit.

So does forcedirectio. ...and it also impacts the performance of reads
for the entire NFS mount.

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@xxxxxxxxxx
www.netapp.com

��.n��������+%������w��{.n�����{��w���jg��������ݢj����G�������j:+v���w�m������w�������h�����٥



[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux