Duplicate SMB file_ids leading to Windows client cache poisoning

[Steven Engelhardt]

>> We would appreciate any guidance on the correct long-term resolution 
>> of this issue.
> 
> It will use the oldest one of atime, mtime or ctime. What is your servers's filesystem timestamp granularity?
> 
> Can you share the result of running stat cli command on files that triggered the issue? Or just generally share info about your filesystem and its timestamp granularity?

Sure.  Using the statres tool (provided in a previous email):

Estimated stat.st_mtim (and friends) resolution:

Ubuntu 18.04 on an Azure Standard_D5_v2: 0.003999954s
Ubuntu 18.04 on an Azure Standard_DS5_v2: 0.004000163s
Ubuntu 18.04 on WSL2 (used for local development & testing): 0.010000000s

> I'm thinking that maybe we should just use the current time for the  itime as returned by clock_gettime_mono().

Sure, but a notable alternatives include pure-random or something like Twitter's Snowflake
id generation algorithm as in https://blog.twitter.com/engineering/en_us/a/2010/announcing-snowflake.

Steve