Performance Enhancements for Samba/VMS 2.2.4

[kenl at genyc.com]

Hello:

I seemed to be a little confused here as the function of the new logical.

I downloaded version 2.2.4 the version dated September 9th.  This seemed to 
install at the time nicely, but yes there was a performance issue.

Today I downloaded the version 2.2.4 dated December 17, and yes there is an 
improvement once the session is created on the alpha from windows for browsing.

Interesting though, I have a directory with all my log files, VFC format where 
I have a web interface for my users to review over night logfiles.  The when I 
open the previous version, the display (though slow) displays perfectly, better 
than EDT.

However, the December 17 version, when display the log files, yes there are 
special characters as you describe in there.  I played with the logical as you 
suggested, ie disabled it etc, and turning it off, makes it totally unreadable.

So I guess my question is, does this logical set it back to the function of the 
earlier version of release 2.2.4.

And yes, I am using wordpad, and I tried notepad, both seem to be the same.

The version I downloaded did come from your site today.

Kenneth Lang





Quoting jean-yves.collot at cofiroute.fr:

> Hi.
> 
> There is a new version of Samba/VMS 2.2.4 that can be found, as usual,
> at
> http://www.pi-net.dyndns.org/anonymous/jyc/
> 
> This version gives (I think) quite important peormance enhancements,
> especially about the time needed for browsing directories.
> 
> The performance problem is due to two factors :
> 
> 1. There is a great number of calls to stat() for the same file, and
> stat()
> on VMS is quite time-consuming. One option, as Mr Carl Perkins proposed
> in
> this mailing list, would be to rewrite stat() completely, and optimize
> it by
> directly reading the INDEXF.SYS file. for the time being, I did not
> choose
> that option, because it looks too much "undocumented" to me, and a
> little
> complicated too. The format of the INDEXF.SYS file and of the file
> headers
> are not supposed to stay the way they are forever. Even today, you
> would
> have to deal with ODS-5 and ODS-2 different structures.
> However, I agree it could dramatically enhance the performance.
> My option was to reduce the actual calls to stat() by caching the
> information, and keeping it in memory as long as possible (i.e. as long
> as
> it has a chance to be accurate). I did this by using the "Volume
> lock",
> which value block is changed each time the structure of the volume is
> changed (file creation/deletion,...). As far as my tests are accurate,
> it
> seems to divide by 3 or 4 the number of actual calls to stat()
> 
> 2. The other reason is that, for variable-record and VFC files, I had
> to
> actually read the file in order to know its real size. When you call
> stat(),
> VMS gives you the actual number of bytes in the file. However, if you
> read
> it record by record, and format each record with and ending <CR><LF>,
> for
> making it useable by Windows, the actual number of bytes you send is
> slightly lower than the number of bytes given by stat(). This has no
> importance for most Windows tools and product (notepad, word, excel,
> etc...). If you use WORDPAD, however, you'll see some additional
> characters
> at the end of the file. This is because WORDPAD first asks for the size
> of
> the file, then reads the file, and pads with zeroes if the number of
> bytes
> obtained is lower than the previously obtained size.
> For those of you that have no need for editing variable-record VMS
> files
> using WORDPAD, I added a logical name (SAMBA_REAL_FILE_SIZE), that is
> defined by default in SMBD_STARTUP.COM, but that you can remove. If
> you
> remove it, no special size checking is done, and the overall performance
> is
> dramatically enhanced for directories with numerous and/or big
> Variable-record files.
> 
> So, if you feel like it, please download and test the new Samba/VMS
> 2.2.4. I
> think (and hope) that you'll be happy with its new performances.
> 
> Merry Chritsmas to all of you.
> 
> Jean-Yves Collot
> 
>