[Samba] speed of samba vs Windows (long and not very conclusive)

[Linda W]

Todor Fassl wrote:
> From: "Cain, Marc" <Marc.Cain at seattlecolleges.edu>
> e user's profile folder location (though in the case of Active 
> Directory --
> delivering additional GroupPolicy behaviors). The client's copy of 
> Windows
> is doing the roaming work and it's behavior is determined by local Group
> Policy settings.
>
> Oh, that's a really good point. Even if the Windows client is doing some
> kind of rsync-like download, it would be initiated by the client, not the
> server.
----
    While the work is initiated on the client, how much work is done is
is dictated by the server.

    It is the case that windows volumes can be monitored for changes.
I don't have a windows server to check this out, but I do know what
samba does on *logout* (when it is the slowest). -- it does an open
action to get the status of every file on the remote server, whereas
linux can deliver 'stat' info without opening the file.  On windows,
an open may be 'cheap', because the "inodes" of all files are kept in
in 1 area -- the MFT.    So theoretically, simply looking up a filename
gives you it's time/date stamp, as I understand it.

    On most *nix file systems, the inodes are distributed in directory
blocks sprinkled throughout the file system.  So for each directory
opened, it has to seek to the blocks for that directory and read them --
and begin returning info from all the inodes in that dir.   At the very
least, there will potentially be more seek times if a large number of
directories are processed.  (I say potentially and theoretically -- I don't
have a windows server, so I don't know what it does!)    Also, I'm NOT
real certain these days what is involved in "opening a file" on linux.  I
don't THINK the server NEEDS to seek to the file data for any reason
unless an actual read is attempted, so for Time & Date, the inodes in
the directories should be enough.

    However.  extended attributes are a different story.  They are often
stored like file data some place else on disk -- and if you have long
access lists on files -- on NT, those security descriptors are in the same
place as the Date & Time stamps.   I can only speak with any experience 
about
XFS, but other file systems on linux may operate similarly (I don't know),
But if it is a small descriptor, it can fit in the inode -- but if it is 
large, it
will have separately allocated data blocks -- that probably need to be read
in order to give information to NT regarding access.  So again -- it is
theoretically possible if you have larger access lists on EACH file ...
that it would have to perform an access seek for each file.

    My profile dir (which has a symlinks to my docdir)... by itself
has 149388 files /27062 dirs, & 6.5GB (which is too much for comfortable
login/logout -- I usually pull my network cord)...

    I have a relatively fast server and a 1Gb ethernet.  I've seen it 
take 45 minutes
for a logout.  (had 12G then and didn't know it...).  BUT I know MS can 
restore
over the net an image @ around 65MB/s (and my own apps can hit up to 119MBps
reads and 125MBps writes.    Reads are slower BECAUSE the client is having
to do the requests -- it won't issue another request until the first one 
is done.
Writes though, though, can be queued and, hence, can get full bandwidth.
   
    The smaller the packet size... the longer things take.   To send a 4MB
email in Tbird -- which sends things in 4K packet sizes -- can easily take
well over a minute.  HUGE difference.

    So -- theoretically, the windows server could be faster on profile 
serving for
date/time stamps by a noticeable amount.   Though w/o benching it, I 
couldn't
say for sure. 

Todor wrote:
> The client is *downloading* the files. The server isn't pushing
> them out, "Here, take all these files whether you like it or not." The 
> list
> of files to download would be calculated on the client.
---
    Hopefully you can see why that might be slower... if it was lots of
small requests...


    Note -- that the above doesn't count actual transfer of DATA!!
It's just inspecting the T/D stamps of each and every file.... *sigh*...



BTW -- you can see what is being transfer using wireshark...  It's
not rocket science...  & wireshark can even be config'ed to display
the file names that are being opened  (provided you aren't
using an encrypted connection...).  So you can see files/dirs being
walked, but not necessarily read......

Hope someone finds this to be useful info...