From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Peter Staubach <staubach@redhat.com>
Cc: Neil Brown <neilb@suse.de>, NFS List <nfs@lists.sourceforge.net>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] NFS server does not update mtime on setattr request
Date: Wed, 07 Jun 2006 01:38:26 -0400 [thread overview]
Message-ID: <1149658707.27298.10.camel@localhost> (raw)
In-Reply-To: <4485C3FE.5070504@redhat.com>
On Tue, 2006-06-06 at 14:05 -0400, Peter Staubach wrote:
> On the NFS client side, there was an optimization added which attempted
> to avoid an over the wire call if the size of the file was not going to
> change. This would be great, except for the side effect of the mtime
> on the file needing to change anyway. The solution is just to issue the
> over the wire call anyway, which, as a side effect, updates the mtime and
> ctime fields.
Vetoed!
The current code gets it quite right: if someone calls open(O_TRUNC),
then may_open() calls do_truncate() with the ATTR_MTIME|ATTR_CTIME flags
set. That will cause the client to do the right thing _regardless_ of
the size optimisation.
> On the NFS server side, there was a change to the routine, inode_setattr(),
> which now relies upon the caller to set the ATTR_MTIME and ATTR_CTIME
> flags in ia_valid in addition to the ATTR_SIZE. Previously, this routine
> would force these bits on if the size of the file was not changing. Now,
> this routine relies upon the caller to specify all of the fields which need
> to be updated.
Also wrong.
This change causes the server to do entirely the wrong thing for
truncate()/ftruncate() calls: in the SuSv3 spec, a call that fails to
change the file length is supposed to leave the file entirely unchanged:
that includes mtime/ctime as well as suid/sgid bits.
Cheers,
Trond
next prev parent reply other threads:[~2006-06-07 5:38 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-06 18:05 [PATCH] NFS server does not update mtime on setattr request Peter Staubach
2006-06-07 5:38 ` Trond Myklebust [this message]
2006-06-07 14:44 ` Peter Staubach
2006-06-07 15:17 ` [NFS] " J. Bruce Fields
2006-06-07 15:26 ` Peter Staubach
2006-06-07 15:39 ` Trond Myklebust
2006-06-07 15:44 ` Peter Staubach
2006-06-07 17:17 ` Trond Myklebust
2006-06-07 17:41 ` Peter Staubach
2006-06-07 15:42 ` J. Bruce Fields
2006-06-07 15:50 ` Peter Staubach
2006-06-07 16:03 ` J. Bruce Fields
2006-06-07 16:56 ` Peter Staubach
2006-06-09 0:40 ` Neil Brown
2006-06-09 13:10 ` Peter Staubach
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=1149658707.27298.10.camel@localhost \
--to=trond.myklebust@fys.uio.no \
--cc=linux-kernel@vger.kernel.org \
--cc=neilb@suse.de \
--cc=nfs@lists.sourceforge.net \
--cc=staubach@redhat.com \
/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