Mail Archives: cygwin/2025/12/22/08:58:36
| DMARC-Filter: | OpenDMARC Filter v1.4.2 delorie.com 5BMDwaSn656552
|
| 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 5BMDwaSn656552
|
| 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=ePMY412d
|
| X-Recipient: | archive-cygwin AT delorie DOT com
|
| DKIM-Filter: | OpenDKIM Filter v2.11.0 sourceware.org 997F34BA2E35
|
| DKIM-Signature: | v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
|
| s=default; t=1766411915;
|
| bh=+29K3SXnK8ae7sADw4LJ0fvC44oTlxKKHnzNW779Ees=;
|
| h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe:
|
| List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:
|
| From;
|
| b=ePMY412d4q4cvGh8xLIIL4Lbf7odCw9WEQT7i0///JjE3XRzwSJ50mM7RUfph74aS
|
| hoU/UI79nHb8LsStDnm68McbN0obJjhpEiUqzUw+3sxnYSP/KQDMxuoNkYKr0kcq7p
|
| WJzk2syXn3ygVX8DA0cLjOBzYtpERXf41OhU/nbQ=
|
| X-Original-To: | cygwin AT cygwin DOT com
|
| Delivered-To: | cygwin AT cygwin DOT com
|
| DMARC-Filter: | OpenDMARC Filter v1.4.2 sourceware.org 0AD174BA2E05
|
| ARC-Filter: | OpenARC Filter v1.0.0 sourceware.org 0AD174BA2E05
|
| ARC-Seal: | i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1766411866; cv=none;
|
| b=j6N7TPbQrMSjEsRL4RMh7cHRKjdpmuHn5dpOfgQ0tzeMe744+5D5yMw/kcpZY6khsOAHsM2S/TXjhF5uX45QFLCMwwuoKQzDDSefSELM1bP0C3x9JQLBKuHmm4cgWSZJblKZFia/WoAyqJCoypMLSPNLjdbMYHlpbbmnrV4+IVE=
|
| ARC-Message-Signature: | i=1; a=rsa-sha256; d=sourceware.org; s=key;
|
| t=1766411866; c=relaxed/simple;
|
| bh=f0yyYAf6iENjxKi4bO3WW5cbao0cULIw2EdiPBsPhiM=;
|
| h=DKIM-Signature:Subject:To:From:Message-ID:Date:MIME-Version;
|
| b=SGmiLHEV+4MHqboBDU1H89Poy8lBBWDQQoa77iQccTxL0YFu+M4RRV5WhjnmvHT/q7M6cTg3wMRhOZtx2mI9u9/uJbVrYDZitI/XP3JzGhtLtc4dBWinqUDYgiRlK9RgXjEgEQv0yM9AAlLAGvPPicuMXYsHBr0V2fwwKO16ox4=
|
| ARC-Authentication-Results: | i=1; server2.sourceware.org
|
| DKIM-Filter: | OpenDKIM Filter v2.11.0 sourceware.org 0AD174BA2E05
|
| Subject: | Re: Why is stat slow?
|
| To: | cygwin AT cygwin DOT com
|
| References: | <74bdc787-9099-8e29-492a-588546b6eedb AT cs DOT umass DOT edu>
|
| Organization: | WiseMo A/S
|
| Message-ID: | <459d4abb-14fe-af09-f62d-defe3454e2c3@wisemo.com>
|
| Date: | Mon, 22 Dec 2025 14:57:45 +0100
|
| X-Mailer: | Epyrus/2.1.3
|
| MIME-Version: | 1.0
|
| In-Reply-To: | <74bdc787-9099-8e29-492a-588546b6eedb@cs.umass.edu>
|
| X-BeenThere: | cygwin AT cygwin DOT com
|
| X-Mailman-Version: | 2.1.30
|
| 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: | Jakob Bohm via Cygwin <cygwin AT cygwin DOT com>
|
| Reply-To: | Jakob Bohm <jb-cygwin AT wisemo DOT com>
|
| 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>
|
| X-MIME-Autoconverted: | from base64 to 8bit by delorie.com id 5BMDwaSn656552
|
Dear Eliot,
As a longtime aficionado of these issues, Cygwin/MSYS2 stat() function
is inherently slower than native Linux/WSL stat() syscall, because the
native stat returns data already kept and cached for each file system
inode/MFTE, while the Cygwin emulation goes through a lot of hoops to
synthesize similar information from a variety of file system data . The
call path that uses GetFileInformationByHandle() is the closest to a
native fast implementation, but unfortunately, most 21st century
antivirus solutions tend to initiate a full "scan file on open to
prevent passing infected data to vulnerable applications" cost when
doing the proforma file open to get the file handle needed for the
GetFileInformationByHandle() call or other low risk checks .
Another set of hoops in the stat() code is the synthesis of a simulated
set of mode bits, which tends to bring in the entire ACL
reinterpretation logic as well as detection of various symlink
approximations (it would be faster to simply treat all "reparse points"
as symlinks and add logic to readlink() that deals with the various
native types, but that would loose the ability to create file system
symlinks without the Administrator privilege of creating the more
dangerous system objects also named "symlink" ).
If the false triggering of AV scanning can be avoided, streamlining the
Cygwin stat() code could greatly speed up heavy users of stat() such as
the find and du commands .
On 22/12/2025 06:15, Eliot Moss via Cygwin wrote:
> Dear Cygwin-ers --
>
> I'm sure this has been asked before, more than once, but I am again
> wondering
> what, specifically, makes stat (the program, but presumably also the
> syscall)
> substantially slower on Cygwin compared to stat on WSL2. I am talking
> about
> an external HDD (not solid state) on my D: drive. It shows under WSL
> 2 as
> /mnt/d like this (output of mount):
>
> D:\ on /mnt/d type 9p
> (rw,noatime,aname=drvfs;path=D:\;uid=0;gid=0;symlinkroot=/mnt/,cache=5,access=client,msize=65536,trans=fd,rfd=5,wfd=5)
>
> On Cygwin it shows up like this (yes, mount shows two lines):
>
> D: on /cygdrive/d type ntfs (binary,notexec,posix=0,user)
> D: on /cygdrive/d type ntfs (binary,noacl,posix=0,user,noumount,auto)
>
> My /etc/fstab lines are:
>
> none /cygdrive cygdrive binary,noacl,posix=0,user 0 0
> d: /cygdrive/d ntfs binary,posix=0,user,auto,notexec 0 0
>
> (Presumably this has something to do with two mounts showing ...)
>
> On D; I have a folder with hundreds of 2Gb files (they are backups,
> split into
> 2Gb portions). On Cygwin
>
> time stat <the files> gives
>
> real   2m12.425s
> user   0m0.249s
> sys    0m1.312s
>
> A second run shortly after the first completes very quickly,
> indicating the
> presence of a cache :-) .
>
> time stat <the files> on WSL2 gives:
>
> real   0m2.208s
> user   0m0.026s
> sys    0m0.149s
>
> This is after a reboot, so there is no caching available. So, why is
> Cygwin
> 60 times slower, even when WSL2 has the handicap of having to work
> through the
> 9p adapter / COM surrogate?
>
> Mostly I am curious, but this is also relevant because I rsync this file
> collection to offsite storage, and the stat time is about what it
> takes for
> rsync to start up - it needs to check file times and lengths.
>
> This makes me wonder if there is something we can do to make this
> better, by
> figuring out what WSL2 / 9p are doing ...
>
> Best - Eliot Moss
>
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
- Raw text -