Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com X-Authentication-Warning: fable6.Stanford.EDU: cobbler owned process doing -bs Date: Wed, 3 Jan 2001 00:52:12 -0800 (PST) From: Dan Morris To: cygwin AT sources DOT redhat DOT com Subject: Cygwin fstat and NT caching Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII My supervisor pointed out to me yesterday that "du" takes a long time to run under Cygwin; out of curiosity, I've been looking into the source of the delays, and I'm curious if anyone else has any insights... This is me running 'du' on my entire hard drive under cygwin : dmorris AT SOAPY /edrive $ time du ... blah blah blah ... all my files go by ... disk spins like mad ... ... I get some coffee ... 0 ./cygwin/edrive 1 ./cygwin/.ssh 208758 ./cygwin 7336071 . real 5m35.523s user 0m10.064s sys 0m32.877s Five minutes is a long time. Now this is me running the Windy Tree CommandPack's version of "du" on the same drive, from inside Cygwin (so I can use "time") : dmorris AT SOAPY /edrive $ time /edrive/Program\ Files/utils/commands/du.exe Windy Tree CommandPack - du (diskusage) (C) Copyright 1999 by Windy Tree. More info at www.windytree.com ------------------------------------------------------------------------------- ... files race by quickly ... disk doesn't move ... clearly using cached inodes... 4775838 e:\cygwin\home 0 e:\cygwin\edrive 350 e:\cygwin\.ssh 209518621 e:\cygwin 7494592864 Bytes total in 67845 files, 4516 directories real 0m35.301s user 0m0.170s sys 0m0.120s Thirty seconds for WindyTree, five minutes for Cygwin; this result is repeatable (that is, the result you see above doesn't mean that I'm just running the Cygwin version first, then letting the WindyTree version take advantage of all the caching). Anyone know why this might be? I looked through the du code; the only repeated filesystem access seems to be through stat() and lstat(). So I looked through stat() and lstat(), and I can't see any place where disk flushes are explicitly forced, or any place where Win32 calls are made with specific flags for ignoring the inode cache ... these seem to be the Win32 filesystem calls that get made : GetVolumeInformation GetDriveType GetFileInformationByHandle GetFileSize GetFileType FindFirstFile I don't know why any of them would ignore the cache... any ideas? I'm running Win2000, if that helps anyone... Thanks... -Dan Dan Morris http://techhouse.brown.edu/dmorris Tiqit Computers http://www.tiqit.com -- Want to unsubscribe from this list? Check out: http://cygwin.com/ml/#unsubscribe-simple