[linux-cifs-client] Re: noatime option for CIFS

Steve French (smfltc) smfltc at us.ibm.com
Mon Jul 31 03:19:01 GMT 2006


After looking at the cifs code more before, I am not sure that there is 
an atime problem

cifs sets NOATIME flag (locally in memory) on its inodes, although since 
it does not set it
on the superblock as we do with NODIRATIME it is harder to notice.   The 
end result
though appears to be what most would want ie that for cifs mounts the 
vfs routine
    "touch atime"
on the client does not do anything (which improves performance) - atime 
of course may be updated
on the server (and usually would be) depending on the local filesystem 
under the server.

What is harder to tell is whether when cifs sets i_atime in a few places 
whether that ends up
indirectly causing the vfs to think the inode is dirty and call 
cifs_setattr.  This is hard to tell
since cifs is only caching inode metadata (such as the timestamps) for 1 
second -
see cifs's revalidate routine IIRC in fs/cifs/dir.c) but a well 
constructed experiment
with repeated stats of a cifs file (multiple times within a second) 
should be able to
tell whether atime is updated or not - or whether cifs simply reflects 
the value on the
server that will be indirectly hit every second by cifs_revalidate.

What would be interesting to find out is:
1) whether in cifs_revalidate the inode metadata caching should be 
configurable
instead of simply being fixed at 1 second
2) whether cifs should add a new mount parm which is the opposite of
noatime (ie "atime") to turn off the noatime flag on cifs inodes (if an app
really wanted atime updated more frequently)

Presumably since cifs is always setting NOATIME on inodes then we should 
show that
mount flag in the superblock (like NFS?)


>Similar to the case of other protocols, if the server updates the atime, 
>the client will eventually reflect this change.   Some local filesystems 
>on the server can not be mounted with "noatime."  In the absense of 
>mounting the  filesystem (on the server) with noatime or equivalent all 
>local access to a fille (inode) including access from the Samba server 
>(indirectly generated by the client) - will update atime on the server 
>(and eventually cause the client's atime to be updated).
>
>The reason for the noatime option on nfs (and why I would consider it 
>worth investigating for cifs) as I understand it, is to increase network 
>performance and to avoid unnecessary setattr calls to flow across the 
>network (SMB SetPathInfo is sent less often).
>
>In addition to noatime (to set atime less frequently), querying timestamps 
>across the network too often is a performance cost - CIFS caches 
>timestamps (and filesize) for 1 second to reduce network traffic.   In 
>order to handle very slow links, this should be configurable via a mount 
>parm (to reduce the getattr, ie SMB QueryPathInfo calls to a minimum)
>
>I should expose the create time - but not sure the best way to do this 
>(probably via an xattr, ie getfattr) and also the dos attributes.  For the 
>dos attributes we should return them in the same format that Samba sets 
>them (I forget the name - but it is fairly easy to spot in the source for 
>Samba)
>
>"Kevin Wilcox" wrote: 
>
>  
>
>>On 7/28/06, Steven French <sfrench at us.ibm.com> wrote:
>>    
>>
>>>I think it would be on the order of 50 to 150 lines of code.
>>>
>>>A few lines in fs/cifs/connect.c to parse_mount_options and much of
>>>
>>>rest in inode.c in cifs_setattr and perhaps cifs_revalidate
>>>
>>>Probably not hard.
>>>
>>>A reasonably simple testcase (better than scripts that do ls/stat ) 
>>>
>>>      
>>>
>>Steve,
>>
>>I'm really sorry to bother you so much. What I still don't understand
>>is how are you going to convey to the CIFS server to not update the
>>last access time? I didn't see any provisions in the CIFS protcol for
>>this.
>>
>>    
>>



More information about the linux-cifs-client mailing list