Duplicate SMB file_ids leading to Windows client cache poisoning

[Tom Talpey]

On 12/8/2021 3:08 PM, Steven Engelhardt via samba-technical wrote:
>>> 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.

I have to say that I'm siding with Steve on not using timestamps,
even with a monotonicity salt. They're terribly old-school and
for good reason. If you want reliable results when running on
everything from embedded ARM systems with FAT (2-second granularity)
on an MMC card, all the way up to servers with PMEM (<<1us access
time) and networks with 100+ Gbps pipes, timestamps will be
whack-a-mole for many years. MHO.

Tom.