Messages in this thread | | | Subject | Re: ctime set by truncate even if NOCMTIME requested | From | Trond Myklebust <> | Date | Tue, 20 Sep 2005 08:12:25 -0400 |
| |
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
- 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/
| |