DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 5BMDkLiR642504 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 5BMDkLiR642504 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=t4nTjgRl X-Recipient: archive-cygwin AT delorie DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 086884BA2E2D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1766411180; bh=HyOlRisTwn+L1DQq6Un3IIffOWiXptPaVH6mzEGyZhA=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=t4nTjgRl+NgeDnQ15QSwxGVid/YLZrXAV322Qc3Hxq4cni8x3JE6DjhrF1HMPJAjJ z3eWWxlkROcZbUCvse00Pe3ASd6PWBcH18OFXEhnkhXZIcvat7RLkK62tuFN9qdR/f irCX52FlLAoVqm94Db7u6UYcGL06wnwN69pjWog4= X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 48C854BA2E04 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 48C854BA2E04 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1766411160; cv=none; b=DTmWP13cVzSQvs1YKpmfLLW3464RqaFScVeM+wxCE7Ewm8IWvjqRIZfdr0CPbEq3XTH6q7QB4UC6SZNXdNvwcCdZ3WEGaEfZrG2RPGmucP4Q3STk0+J9sVX3pNKSIJDcoWtbtYqGh74+J/mLz1WMawMXmin7txqiVnq8Djqk2Og= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1766411160; c=relaxed/simple; bh=Pou7EeCfGLq5E8m+juyEpAEHHl1mAnjpCqYeRcI3sko=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=PRrhTVlZH0u8ihucm6eKaplr0oWIQQ6MfxWBFH+OEkRHiBgrhycxZjQXASH1tYTO0XHh5zDzsjZkavSIV1N73spwNx0Uhxm0LDoNj/96U/an3xEsLQvjJT1vh/o4xkU6YR0IpewnFvKY70gPYe+4SNxSJhfhEP6ULQ4x7HaEkSg= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 48C854BA2E04 X-Barracuda-Envelope-From: moss AT cs DOT umass DOT edu X-Barracuda-RBL-Trusted-Forwarder: 128.119.240.136 DKIM-Filter: OpenDKIM Filter v2.11.0 mailsrv.cs.umass.edu CD35E5BDA0 X-Barracuda-RBL-Trusted-Forwarder: 172.26.69.67 Message-ID: Date: Mon, 22 Dec 2025 08:45:57 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: Why is stat slow? Content-Language: en-US X-ASG-Orig-Subj: Re: Why is stat slow? To: Marco Atzeri , cygwin AT cygwin DOT com References: <74bdc787-9099-8e29-492a-588546b6eedb AT cs DOT umass DOT edu> <5f1fb088-7f4b-4858-87b7-e1d89f5c7334 AT gmail DOT com> In-Reply-To: <5f1fb088-7f4b-4858-87b7-e1d89f5c7334@gmail.com> X-Barracuda-Connect: mailsrv.cs.umass.edu[128.119.240.136] X-Barracuda-Start-Time: 1766411159 X-Barracuda-Encrypted: TLS_AES_256_GCM_SHA384 X-Barracuda-URL: https://barramail.cs.umass.edu:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at cs.umass.edu X-Barracuda-Scan-Msg-Size: 3731 X-Barracuda-BRTS-Status: 1 X-ASG-Debug-ID: 1766411159-24039d6c3d4edc60001-w5GHUG X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=3.5 QUARANTINE_LEVEL=10.0 KILL_LEVEL=9.7 test= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.125474 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-BeenThere: cygwin AT cygwin DOT com X-Mailman-Version: 2.1.30 List-Id: General Cygwin discussions and problem reports List-Archive: List-Post: List-Help: List-Subscribe: , From: Eliot Moss via Cygwin Reply-To: Eliot Moss Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "Cygwin" 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 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 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