On Mon, Nov 1, 2010 at 1:00 PM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > On Mon, 1 Nov 2010 12:41:31 -0500 > Steve French <smfrench@xxxxxxxxx> wrote: > >> My reaction is that over modern networks 1 second attribute timeout is >> probably ok and 60 seconds is too slow (certainly slowing it down >> beyond 5 seconds could be noticeable to user, not just create a higher >> data integrity risk) - but the obvious exception is over slow >> networks. Since we can get the SMB echo times - we could base the >> value of actimeout 1 second vs 60 second based on what we estimate >> round trip delay is. >> > > I don't see any connection between the ac timeout and round trip time. > The ac timeout needs to be set according to how often you expect files > to change, and that has no real relation to the RTT between client and > server. If a qpathinfo/qfileinfo is not returned in 1 or 2 milliseconds - I can see your point - but that is why you might want to use round trip time as a factor in deciding to make attribute timeout visible. At 1 second, a user rarely notices the timestamp being "incorrect" (stale due to update of file on other system) - at 60seconds it would be very easy for a user to get puzzled why the timestamp was wrong. The choice of 1 second was chosen partly to match ext3 - with the common server file system having 1 second time granularity always doing queryfileinfo for stat on non-cached files was unnecessary. Applications that relied on reflecting subsecond time granularity would be broken on ext3 anyway. Going beyond 4 or 5 seconds though, the user would notice file changes and there is plenty of time for user to go to one machine change a file, and then get confused why the change is not reflected on the other. -- Thanks, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
