Re: ctime set by truncate even if NOCMTIME requested

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Trond Myklebust wrote:


However if you know the cases where time is set implicitly by the
server, why can't you simply optimise away the ATTR_CTIME and/or
ATTR_MTIME?

I don't see any case other than explicit application calls on the client to utime in which we would ever want the client to send its timestamp to the server.

The cases that have to be checked for for the cifs client case are few - setting the file size (truncate/ftruncate) and chmod/chown (which sets CTIME on the client, not just the setting the mode) and in my traces they do look different in setattr than calls to setattr that come through utimes. For example, it probably is safe to assume that ctime never has to be sent to the server when also one or more of the the mode, owner or size is being set - and no other user space application (just via the truncate system call) would ever call notify_change (setattr) for both size and time, but it does make me nervous to throw away any request to update the timestamps remotely if the size is also changing (the change of the file size does need to go to the server). It does seem like
   utime(filename, timeval)
may be the only time we want to send time changes to the server but I am not certain how risky such an approach is even after scanning fs/open.c to ignore time changes except when both ATIME/MTIME/CTIME are set at the same time (as they are in sys_utime and do_utimes). Most people probably don't care if the server and client clocks are not too far off, but it does affect performance (presumably even noticeable on something like fsx test)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]
  Powered by Linux