Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sources DOT redhat DOT com
Message-ID: <17B78BDF120BD411B70100500422FC6309E1B0@IIS000>
From: Bernard Dautrevaux <Dautrevaux AT microprocess DOT com>
To: "'Dan Morris'" <dmorris AT tiqit DOT com>, cygwin AT sources DOT redhat DOT com
Subject: RE: Cygwin fstat and NT caching
Date: Wed, 3 Jan 2001 16:30:50 +0100 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"

> -----Original Message-----
> From: Dan Morris [mailto:dmorris AT tiqit DOT com]
> Sent: Wednesday, January 03, 2001 9:52 AM
> To: cygwin AT sources DOT redhat DOT com
> Subject: Cygwin fstat and NT caching
> 
> 
> 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.

Not so damned bad in fact :-)

Don't forget your disk seems to be 7.5 GigaBytes long! On my Linux box, with
Fast&Wide SCSI disks, getting a "du -s ." on a drive wheer 2.3 GigaBytes are
used takes 30sec real time (approx. 10sec CPU time) first run and 10sec
successive runs, so extrapolating to 7Gigabytes give not far from 2 minutes
for a non-cached du and 30sec for a cached one.

Here I have a dual PentiumIII-550MHz with very fast disks and 1GigaByte of
RAM so Linux can use big caches; a 2 to 3-fold increase could be expected,
depending on your hardware (you give no indication about it).

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

30 sec is what I would expect for a fast machine using cached info for about
7Gbytes (if you have plenty of memory of course).

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

Probably this may have to do with the way cygwin define permissions for
files: to know if a file is executable, stat() has to READ the file itself,
thus adding disk traffic that can very difficultly be cached, especially
with a 7.5Gigabytes disk usage... Just that could be enough to flush
completely the disk cache :-)

Regards,

	Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux AT microprocess DOT com
		b DOT dautrevaux AT usa DOT net
-------------------------------------------- 

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple