Re: Ideas how to improve Cygwin /usr/bin/find, rm -Rf etc. performance...

Jakob Bohm via Cygwin <[email protected]>
Newsgroups gmane.os.cygwin
Organization WiseMo A/S
Message-ID <[email protected]>
On 02/03/2026 23:42, Roland Mainz via Cygwin wrote:
> Hi!
>
> ----
>
> Quick note (mainly for Corinna):
> Cygwin 3.7.0, I noticed a possible performance improvement while
> working on ms-nfs41-client:
> For each file/dir listed by /usr/bin/find, rm -Rf .. etc I see two
> QueryVolumeInformation (volumequery class=1 and class=4) which
> technically could be cached per mount+process.
>
> I also recall an old confcall at SUN around |openat(dirfd, ...)|,
> technically this info could also be cached per-dirfd (and inherited if
> the dirfd is used to |openat()| another dir fd), making such a cache
> last longer...
The hard part of this is to quickly (without slowing down the total)
detect if a subdirectory is a mountpoint for some other location
(possibly within the same file system, yes windows has had the equivalent
of bind mounts ever since the MSDOS added the JOIN command).

Similarly, find --xdev etc. should stop at such subdir mounts that don't
change st_dev (kernel/cygwin1 changes that assign virtual IDs to each bind
mount don't work as they would hurt other uses of st_dev).

A more practical way until POSIX agrees on a solution is for cygwin to
keep an in-process cache per "volume serial number" from the
GetFileInformaionByHandle() equivalant of fstat()


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded


-- 
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.