Re: 1.5.20-1: ls -F slowness

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

On Nov 20 09:30, Scott Roland wrote:
> So if the SMB server is not being used much then the ls -F has no
> problems, unfortunately this is not the normal situation. I still don't
> have any clue as to what the 1.5.20 or newer versions would be doing
> special that make them slower than the 1.5.19 and earlier versions. (Are
> the newer versions parallelizing the system calls and our server ends up
> thrashing its cache?)

One difference from the point of view of the file server would be that
directories are read (aka "readdir") in chunks of 100 entries in one go
instead of reading the directory one entry at a time.  Another one would
be the fact that on servers supporting it, the file IDs (aka "inode
numbers") are read, too, which wasn't done in 1.5.19.  If the file
server does not support the SMB_FIND_ID_BOTH_DIRECTORY_INFO level, the
result is that one extra call per file is made to retrieve the file ID.
That would happen when

- running on NT4 or earlier.
- accessing remote NT4 and W2K shares.
- accessing remote shares from W2K.
- accessing remote shares on Samba versions below 3.0.
- accessing remote shares on Samba versions below 3.0.22 for
  directories with roughly more than 128 entries.


Corinna

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

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/