DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 51R8oebr565829
Authentication-Results: delorie.com; dmarc=pass (p=none dis=none) header.from=cygwin.com
Authentication-Results: delorie.com; spf=pass smtp.mailfrom=cygwin.com
DKIM-Filter: OpenDKIM Filter v2.11.0 delorie.com 51R8oebr565829
Authentication-Results: delorie.com;
	dkim=pass (1024-bit key, unprotected) header.d=cygwin.com header.i=@cygwin.com header.a=rsa-sha256 header.s=default header.b=MM45mTdM
X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9B1BD3858C30
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1740646238;
	bh=j5DKBVKgaA+XSMOcy2AEmuJ/V9cj8Has/szqlvpIbP8=;
	h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe:
	 List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:
	 From;
	b=MM45mTdM9klGDlRLU+XH1Yxxo5E21gsaDmN5nBKACQXGbndMDpkf3Nw8KumdA9siM
	 Cp6l3MvxcR8DdqeJVW3ZxJkg7XxH2FierDDtzS4zD2Jfhhi3ndEAZRMMJdnk9ujFyP
	 SxCZEVlz4g6WNQ/VQo30T0O6RY7M5xbAWXpKLrec=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 294F53858D28
Date: Thu, 27 Feb 2025 09:49:40 +0100
To: cygwin AT cygwin DOT com
Subject: Re: rm -Rfv on UNC path horribly slow in Cygwin
 3.6.0-0.404.g323729f654ae.x86_64 ...
Message-ID: <Z8AnJCOpObDQMxbC@calimero.vinschen.de>
Mail-Followup-To: cygwin AT cygwin DOT com
References: <CAKAoaQniATLryoaKnpFwYXcLOU4VViHE+fUHA_nTz6omxTZc4w AT mail DOT gmail DOT com>
 <Z795BWjJd7bPNgGj AT calimero DOT vinschen DOT de>
 <CAKAoaQkmBT-FNvLUCv=wNy6MXGiMxvkWnS74NB9h2U8RZ_wuTQ AT mail DOT gmail DOT com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAKAoaQkmBT-FNvLUCv=wNy6MXGiMxvkWnS74NB9h2U8RZ_wuTQ@mail.gmail.com>
X-BeenThere: cygwin AT cygwin DOT com
X-Mailman-Version: 2.1.30
Precedence: list
List-Id: General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe: <https://cygwin.com/mailman/options/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive: <https://cygwin.com/pipermail/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe: <https://cygwin.com/mailman/listinfo/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From: Corinna Vinschen via Cygwin <cygwin AT cygwin DOT com>
Reply-To: cygwin AT cygwin DOT com
Cc: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
Content-Type: text/plain; charset="utf-8"
Errors-To: cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com
Sender: "Cygwin" <cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by delorie.com id 51R8oebr565829

On Feb 27 05:58, Roland Mainz via Cygwin wrote:
> On Wed, Feb 26, 2025 at 9:26 PM Corinna Vinschen via Cygwin
> <cygwin AT cygwin DOT 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 AT 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