Samba consumes a lot of resources

[Carl Perkins]

>It takes 8 seconds to open my home directory which has 413 files
>(including sub-directories, i.e. *.DIR files).

This is not very slow, considering that the hardware you are using
is old.

This new version is also a LOT faster than earlier versions of Samba
on VMS. For me, moving from 2.0.6 to 2.2.7a speed directory listing
up by a factor of 5 or more for the first listing of a directory,
and better than that for subsequent accesses when nothing has changed.

The timings for the limited testing that I did with V2.0.6 vs. V 2.2.7a.

Directory  2.0.6  2.2.7a
---------  -----  ------
A          36.3   2
B          24     2.7
C          124.7  13.3

Notes: Each time is in seconds and is the average of 3 runs done
while the system was lightly loaded, if at all. For 2.2.7a, the
first of the three times was anywhere from a bit over 1.1 up to
1.7 times the average - the new cache usually brings the time down
a lot for the later accesses. For example, the actual timings of
the accesses for directory C were 22, 2, and 16 seconds. Note that
"2" in there and compare it to the timings with the old version of
127, 114, and 133 seconds. (There was presumably a cache flush due
to the disk having been modified shortly before the 3rd access with
the new version. It had to be shortly before because the test for
directory B, on the same drive, done immediatly prior to this did
not show this increase - it had a time of 1 second for the 3rd access.)

Directory A held about 295 files, 50 of which were subdirectories.
Directory B held about 225 files, 119 of which were subdirectories.
Directory C held about 1176 files, 2 of which were subdirectories.

Directory A is on a locally attached disk that is farly fast (on the XP900
that is the Samba server). Directories B and C are on another system in
the cluster (coincidentally it is, like your system, a DEC 3000 model 600)
and therefore also includes some MSCP serving overhead via that system's
10Mbit/sec connection.

The number of subdirectories is important since in addition to getting
the data (name, size, and dates at least - I'm not sure what else) on
the files in the directory in question, it also checks each of the the
subdirectories one at a time for a desktop.ini file (at least - it may
check for more; it is also known to try to open a variety of files in
the current directory as well).

So you should consider that 8 second time in comparison to what it
would be if you were using version 2.0.6 - with that older version
it would probably take over 2 minutes for your directory listing to
show up.

> I am testing on loriot: VMS 7.3, Samba 2.2.7a, and MultiNet V4.4 Rev A
> on DEC 3000 Model 600 with 384 MB memory. After solving the "Flags =3D
>
>Claude Marinier, Information Technology

The DEC 3000m600 design is about 9 years old. It is a 175MHz Alpha
of the EV4 variety - some 2 full generations plus a couple process
shrinks behind current Alpha systems (and about to become 3 full
generations later this month when the EV7 based systems are officially
announced next week). It was the fastest desktop computer available when
it came out, but it it quite slow by todays standards.

You really should not compare the speed accessing stuff on it to a new
PC (if you want to compare a new PC to an Alpha, then to be fair it
should be a new Alpha). If you want to compare it to something, you
should compare it to a roughly equivalent PC. That would be a plain
old Pentium (no number) running at something in the vicinity of 120MHz.
Your system has a bigger cache and better I/O than such a PC, but at
120MHz the Pentium had a bit better integer operation performance
(and a little worse floating point). The DEC 3000m600 also has 10 Mb/sec
ethernet built in and you are most likely using that (I think there
was a 10-base100 Turbochannel card that you could get a couple of years
after this system came out, but I'm not certain), so that is also limiting
compared to the now standard 100Mb/sec interfaces in PCs.

I don't think you would be surprised if accessing things on a 120MHz
Pentium system was a bit slow. Likewise, it should not surprise you
that a roughly 9 year old Alpha system doesn't have very good
performance - in fact, it might be surprising that Samba on it is
as fast as it is.

As for what works and what doesn't...

3 things that I know do not work for me with version 2.2.7a:

- I can not use Microsoft Excel's "Save As..." option to save a file
to the Samba server. It fails, giving two errors, includig one that
suggests that the share may be read-only. I can modify an existing
.XLS file, although my brief test probably didn't cause it to need
to allocate more space on disk.

- I can not create a new Microsoft Excel spreadsheet by right-clicking
in Explorer and picking the MS Excel file type off of the context
menu's "New" list. This is probably for the same reason as the previous
problem, whatever that is. (My current guess, without evidence but with
knowledge of problems that v2.0.6 has, is that it is probably related
to OLE locking - the way these high byte range lock requests are being
handled, however that is, may be failing during the creation of new
files.)

- There was some 3rd thing that was not related to Excel which I can't
remember at the moment.

As I recall, one, or possibly both, of the first two things did leave a
new empty file in the directory. I think it was using the "New" context
menu to try and create the file. As I recall, it was then possible to
open this new, poorly named, file in Excel and proceed with using it,
but I didn't save any data when I did so I can't be certain it really
works properly after that.

--- Carl