lkml.org 
[lkml]   [2005]   [May]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: NFS: msync required for data writes to server?
From
Date
to den 12.05.2005 Klokka 19:42 (-0700) skreiv Andrew Morton:
> > Looking at the differences in fs/nfs between these trees I found a
> > change to nfs_file_release() in fs/nfs/file.c. When I applied this
> > change to my 2.6.9 tree, the data was written out to the server.
> >
> > @@ -105,6 +108,9 @@
> > static int
> > nfs_file_release(struct inode *inode, struct file *filp)
> > {
> > + /* Ensure that dirty pages are flushed out with the right creds
> > */
> > + if (filp->f_mode & FMODE_WRITE)
> > + filemap_fdatawrite(filp->f_mapping);
> > return NFS_PROTO(inode)->file_release(inode, filp);
> > }
>
> Well yes, that'll sync the file on close, but it doesn't explain the
> original problem.

See the above comment and the changelog entry for that patch. The
problem is and was that writepage() does not take a struct file
argument, and so we have to guess which RPC credentials to use when
writing out the dirty pages.

Before we had RPCSEC_GSS, we could cache the credential of the last
person who opened the file, and expect that it would be usable for
writing out dirty pages since the AUTH_SYS credentials have an infinite
lifetime. With the advent of strong security, and credentials with a
finite lifetime, that became risky behaviour, and so we now actually
look for which files are still open at the moment when writepage is
called.
The problem was that the VFS does not flush dirty pages to disk on
file_release(), and hence the above patch which at least will do it for
NFS.

Cheers,
Trond

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-05-13 05:52    [W:0.040 / U:5.824 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site