This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: Cygwin Filesystem Performance degradation 1.7.5 vs 1.7.7, and methods for improving performance
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin-developers at cygwin dot com
- Date: Mon, 4 Oct 2010 12:28:26 +0200
- Subject: Re: Cygwin Filesystem Performance degradation 1.7.5 vs 1.7.7, and methods for improving performance
- References: <4CA8DE6D.3080006@cwilson.fastmail.fm> <4CA8FC5B.1090307@hola.org>
- Reply-to: cygwin-developers at cygwin dot com
On Oct 3 23:57, Derry Shribman wrote:
> Hi,
>
> > BZZZT. Thanks for playing.
> > find cvs-1.12.13 -type f | xargs grep 'st_ino'
> > shows 35 different uses of the st_ino member of struct stat.
>
> grep st_nlink: zero results.
>
> > find make-3.81 -type f | xargs grep 'st_ino' |wc
> > shows 11 different uses of the st_ino member of struct stat.
>
> grep st_nlink: zero results.
>
> st_ino information IS retrieved.
>
> See Yoni's post of the cygtest.c application to test the stat()
> performance: It calls NtQueryDirectoryFile() with
> FILE_ID_BOTH_DIR_INFO, at st_ino is in fdi.FileId field.
It doesn't matter anyway. If you don't fetch st_nlink to recognize
files with more than one link, then st_ino doesn't matter anymore
and it can also just be a hash value. What does it mean to have
two files with the same inode number on the same device, both having
a link count of 1? A broken filesystem?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat