On Feb 27 05:58, Roland Mainz via Cygwin wrote: > On Wed, Feb 26, 2025 at 9:26 PM Corinna Vinschen via Cygwin > <cygwin@cygwin.com> wrote: > > On Feb 26 20:16, Roland Mainz via Cygwin wrote: > > > Something is wrong with UNC paths in Cygwin 3.6 build > > > 3.6.0-0.404.g323729f654ae.x86_64 and ms-nfs41-client 2025-02-21: > > > > > > Example: > > > ---- snip ---- > > > [...] > > > ---- snip ---- > > > > > > Each line from rm -Rfv now needs around 3-5 seconds. Switching to CWD > > > //derfwnb4966_ipv4@2049/nfs4/bigdisk/builds/bash_build1 (e.g. non-FQDN > > > for share host) does not fix the problem. Going to > > > /cygdrive/l/builds/bash_build1 and the rm -Rfv deletes around 70-90 > > > files per second. > > > Last tested version was Cygwin commit > > > #4bcc6adec765ee8354bfc9e6c060c9d1c0c7bf46 (and same ms-nfs41-client > > > 2025-02-21 release), rm -Rfv performance there was normal (same as on > > > /cygdrive/l/...). > > > > I can't reproduce this on MS NFS and SMB. > > > > You should try this with the latest 406 build. > > Done, works perfectly - see below, the issue was something different...
I'm glad to read that. > > If this doesn't fix > > it, I need to know which test release introduced this problem. > > It turns out this is something very NFSv4.x-specific: Delegations! > > A NFSv4.x server can grant a client a "read" or "write" delegation. A > client can cache reads or read/writes locally if the server grants > that delegation. If another client touches the file for which the > server has granted a delegation to another client, the delegation must > be recalled first and the caller gets a |NFS4ERR_DELAY|, and has to > re-try after a delay. > > And this happens in this case, because the mounts I used for testing > are (intentionally [1]) treated as separate clients. > > [1]=First it's my test setup, and secondly the ms-nfs41-client is > highly threaded to deal with the async nature of the Windows kernel > and NFSv4.x's nature of being able to handle requests in parallel, the > only limiting factor being TCP and the RPC implementations's locking. > > Wireshark documented this nicely: > ---- snip ---- > [...] > ---- snip ---- > > So everything is working as expected, but I really need a FSCTL_* to > flush all delegations for accurate performance benchmarking. > > Does the Win32 have a "flush cache"-|FSCTL_*|/|IOCTL_*| ? I don't know any FSCTL/IOCTL for that. I'm only aware of the FlushFileBuffers() call for single files, as well as the SetSystemFileCacheSize() function as a way to flush the entire filesystem cache. There's also a way to flush the cache for a single filesystem, but I think this works only for local filesystems: https://stackoverflow.com/questions/7405868/how-can-i-invalidate-the-file-system-cache Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
