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
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
WARNING: multiple messages have this Message-ID (diff)
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:39 UTC|newest]
Thread overview: 25+ 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 5:38 ` Trond Myklebust
2006-06-07 14:44 ` Peter Staubach
2006-06-07 14:44 ` Peter Staubach
2006-06-07 15:17 ` J. Bruce Fields
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:39 ` [NFS] " Trond Myklebust
2006-06-07 15:44 ` Peter Staubach
2006-06-07 15:44 ` [NFS] " 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:42 ` [NFS] " 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-07 16:56 ` [NFS] " Peter Staubach
2006-06-07 15:28 ` reservas
2006-06-09 0:40 ` Neil Brown
2006-06-09 0:40 ` [NFS] " Neil Brown
2006-06-09 13:10 ` Peter Staubach
2006-06-09 13:10 ` [NFS] " 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.