From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: smfrench@austin.rr.com, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: ctime set by truncate even if NOCMTIME requested
Date: Tue, 20 Sep 2005 08:12:25 -0400 [thread overview]
Message-ID: <1127218345.8413.32.camel@lade.trondhjem.org> (raw)
In-Reply-To: <E1EHf0E-000197-00@dorka.pomaz.szeredi.hu>
ty den 20.09.2005 Klokka 12:05 (+0200) skreiv Miklos Szeredi:
> These are othogonal problems.
>
> IS_NOCMTIME is the filesystem's way of saying that it doesn't need
> ->setattr on truncate(), write(), etc. Why? Because it can do the
> [cm]time change implicitly _within_ the operation.
No. IS_NOCMTIME is the filesystem's way of telling the VFS never to
screw around with the values of inode->i_mtime and inode->i_ctime.
The reason is that crap like inode_update_time() explicitly sets these
values to the local current time instead of using server timestamps.
OTOH, ->setattr with an ATTR_MTIME or ATTR_CTIME argument is telling the
filesystem to update the timestamp. The filesystem then has a choice of
whether or not to use current time, server time, or to just ignore it if
the timestamp is going to be be updated by the other ->setattr arguments
anyway.
> ATTR_MTIME is _only_ set in utime[s], which all filesystems want to
> honor.
ATTR_MTIME is set in both utimes and truncate. In the latter case, CIFS
could optimise it away by noting that ATTR_SIZE will set mtime anyway.
As for ATTR_CTIME, that is also set in chown(), chmod(). It too can be
optimised away for those operations, assuming that CIFS servers
automatically update ctime.
Cheers,
Trond
next prev parent reply other threads:[~2005-09-20 12:12 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-19 17:51 Steve French
2005-09-19 18:58 ` Trond Myklebust
2005-09-19 20:58 ` Steve French
2005-09-19 21:28 ` Trond Myklebust
[not found] ` <432F5968.1020106@austin.rr.com>
2005-09-20 1:36 ` Trond Myklebust
2005-09-20 2:16 ` Steve French
2005-09-20 12:11 ` Andreas Dilger
2005-09-20 8:52 ` Miklos Szeredi
2005-09-20 10:05 ` Miklos Szeredi
2005-09-20 12:12 ` Trond Myklebust [this message]
2005-09-20 12:20 ` Miklos Szeredi
2005-09-20 12:27 ` Trond Myklebust
2005-09-20 8:48 ` Miklos Szeredi
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=1127218345.8413.32.camel@lade.trondhjem.org \
--to=trond.myklebust@fys.uio.no \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=smfrench@austin.rr.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
all inboxes | Powered by JetHome®