Re: Why is stat slow?

Eliot Moss via Cygwin <[email protected]>
Newsgroups gmane.os.cygwin
Message-ID <[email protected]>
On 12/22/2025 12:58 AM, Marco Atzeri via Cygwin wrote:
> 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
>>
> 
> I do not notice a slow run.
> The disk is an external 1T USB3 hard disk
> 
> $ time stat /dev/sdb1
>    File: /dev/sdb1
>    Size: 0               Blocks: 0          IO Block: 65536  block special file
> Device: 8,17    Inode: 524305      Links: 1     Device type: 8,17
> Access: (0666/brw-rw-rw-)  Uid: (197608/   Marco)   Gid: (197121/ NESSUNO)
> Access: 2025-12-22 06:55:21.968106000 +0100
> Modify: 2025-12-22 06:55:21.968106000 +0100
> Change: 2025-12-22 06:55:21.968106000 +0100
>   Birth: 2025-12-22 06:55:21.968106000 +0100
> 
> real    0m0.099s
> user    0m0.030s
> sys     0m0.000s
> 
> $ time stat /cygdrive/d
>    File: /cygdrive/d
>    Size: 0               Blocks: 8          IO Block: 65536  directory
> Device: 54787,64366     Inode: 1407374883553285  Links: 1
> Access: (0770/drwxrwx---)  Uid: (   18/  SYSTEM)   Gid: (   18/  SYSTEM)
> Access: 2025-12-21 19:40:02.793348100 +0100
> Modify: 2025-11-11 15:18:10.162456400 +0100
> Change: 2025-11-11 15:18:10.162456400 +0100
>   Birth: 2018-04-11 15:14:25.158842400 +0200
> 
> real    0m0.028s
> user    0m0.015s
> sys     0m0.000s

Thank you for checking, Marco!  I do wonder wonder, though, if those files are
very characteristic.  The first is a block file and the second is a directory.
My timings were for moderately large regular files (2Gb each), about 1300 of
them.  So I guess that either there's something different about my system or
different about the files I was stat-ing.

I also wonder if anyone familiar with the internal code may have thoughts on
this ...

Best - Eliot

-- 
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.