Re: regressions & flakiness make for ugly symlink links

[L A Walsh <cifs@tlinx.org>]

On 2/19/2019 11:46 AM, Pavel Shilovsky wrote:
> пн, 18 февр. 2019 г. в 22:16, L A Walsh <cifs@tlinx.org>:
>   
>> In my Windows root directory I have several links...
>> lrwxrwxrwx   1           17 Jun 13  2016 Documents -> //Bliss/Documents/    
>> lrwxrwxrwx   1           20 Nov  6  2014 Prog -> /Program Files (x86)/
>> lrwxrwxrwx   1           13 Apr 21  2013 Prog64 -> Program Files/
>> lrwxrwxrwx   1           12 Aug  9  2015 ProgD -> /ProgramData/
>>     
...
>> ---
>>
>> Now, I'm getting flaki results -- with them not resolving 1 time,
>> then resolving,  then not again...etc
>>
>> # ll|more
>> ls: cannot access 'Documents': Operation not supported
>> ...
>> ls: cannot access 'Prog64': Operation not supported
>> ...
---
>> d????????? ?       ?            ? Documents/
>> ...
>> d????????? ?       ?            ? Prog64/
>> ...
>> Depending on timing, Sometimes I will get most or all of
>> them appearing the same as they would on windows.
>>
>> If I can't resolve them more quickly, is there a know
>> or two to increase cache size and item lifetime?
>>     
>
> Which kernel version shows symlinks right and which - wrong?
>   
I only recently switched on getting the access info 'live',
vs. mounting it all as 1 user.  Since it works and doesn't
work based on what's in the cache, the same kernel can provide
both symptoms.

I don't remember the exact date I switched, maybe in the 4.19.xx
series, but at the moment, am running 4.20.3.

Sometimes after a client reboot, I'll see question marks for all
files or about 60 entries in the root dir.  Vs. only the symlinks
where it has to do 2 lookups -- the item and the one pointed to,
and see about 10-15 entries.

I figured that it's a timing prob related to whether or not the entries
are in some cache, so I need to look more closely at that
UID<->RID resolution path, but meanwhile, I thought I'd increase
the cache size and maybe look at the timeout value and if I could
tolerate a longer timeout.

So -- don't think it is the kernel version, but the fact that it's
going a long path to do the lookups -- especially the links --
and that optimizing that path would likely bring the most benefits.

There used to be documentation about doing the resolution through
a separate program, but that documenation disappeared as someone
wrote a .dll to do the resolving, which got plopped in there after
an accidental system update attempt (long story -- power outage,
ups needs new batteries, and more).

Anyway, UID/GID<=>RID map is relatively small (<10-15K) with
long-lived entries.  The server has >100GB mem and the
client, 92GB.

That's why I wanted to increase the UID<->RID cache size &
raise the timeout to a long value.  Maybe ideally with a way
to manually invalidate the cache and/or 1 entry for rare updates.

Thanks!