Cygwin Filesystem Performance degradation 1.7.5 vs 1.7.7, and methods for improving performance

Corinna Vinschen corinna-cygwin@cygwin.com
Sun Sep 12 11:55:00 GMT 2010


On Sep 12 13:41, Corinna Vinschen wrote:
> On Sep 12 10:49, Yoni Londner wrote:
> > Hi,
> > 
> > The caching-speed up is trivial:
> > We store the the FileFullDirectoryInformation fields, and if any of
> > them change - we re-read the file.
> > 
> > Its not (in practical life) possible to change a file without
> > causing a modification on FileIndex/CreationTime/LastWriteTime/ChangeTime/EndOfFile/AllocationSize/FileAttributes/FileName/EaSize!
> > 
> > From the MSDN we see the info we can get on a
> > FileFullDirectoryInformation request:
> 
> We're already using FileBothDirectoryInformation and
> FileBothIdDirectoryInformation in readdir anyway.
> 
> However, isn't that kind of a chicken/egg situation?  If you want to
> reuse the content of the FILE_BOTH{_ID}_DIRECTORY_INFORMATION structure
> from a previous call to readdir, you would have to call the
> corresponding NtQueryInformationFile call(s) to fetch the information
> from the file for comparision purposes.  When you fetched it anyway,
> there's no reason anymore to compare them, since you can use what
> you just fetched.  Where's the advantage?

The patch I still have in the loop uses the FILE_NETWORK_OPEN_INFORMATION
structure throughout, starting in symlink_info::check.  The content is
then stored in the path_conv structure and reused in
fhandler_disk_file::fstat_by_handle.  If the content of that structure
would be used as fingerprint, then we could perform readdir/stat caching
without requiring fstatat.  Something similar could be used to perform
ACL caching, so that a typical `ls -l foo' would not request the ACL
two or three times, but only once...


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat



More information about the Cygwin-patches mailing list