mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Andrew Morton <akpm@osdl.org>
Cc: linda.dunaphant@ccur.com, linux-kernel@vger.kernel.org
Subject: Re: NFS: msync required for data writes to server?
Date: Thu, 12 May 2005 20:48:48 -0700	[thread overview]
Message-ID: <1115956128.12175.11.camel@lade.trondhjem.org> (raw)
In-Reply-To: <20050512194210.10a9dc93.akpm@osdl.org>

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


  parent reply	other threads:[~2005-05-13  3:49 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-12 19:21 Linda Dunaphant
2005-05-13  0:57 ` Andrew Morton
2005-05-13  2:21   ` Linda Dunaphant
2005-05-13  2:42     ` Andrew Morton
2005-05-13  3:41       ` Linda Dunaphant
2005-05-13  3:48       ` Trond Myklebust [this message]
2005-05-13 23:57         ` Linda Dunaphant

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1115956128.12175.11.camel@lade.trondhjem.org \
    --to=trond.myklebust@fys.uio.no \
    --cc=akpm@osdl.org \
    --cc=linda.dunaphant@ccur.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®