Constant stat and seek calls.

John E. Malmberg wb8tyw at
Thu Oct 12 04:52:09 GMT 2000

"Ron Alexander" <rcalex at> wrote:

> Can anyone tell me why the fileio.c/read_file routine does
> a seek_file?
> Background:
> 0. samba 2.0.7
> 1. Stratus VOS has a file type called sequential. It is
> Length+Data+Length
> (an old COBOL format?)

OpenVMS has several sequential data types.  When read from a C program they
all appear to be stream format with line feed characters terminating the
records.  When records are written, a reverse translation is done.

> 2. It is the default file type. Our customers have a HUGE
> investment in these files. We are supporting them as
> read-only.

I have them as read/write, but I have found out that there were some issues
when the files get above a certain size.

For one thing, random reads and writes can be problematic if they are not
done on record boundaries.

Neither PC clients or the SAMBA program can be relied on to transfer data on
a record boundary and this will cause file corruption on OpenVMS for these
file types.

> 3. Our BETA site refuses to install samba without the
> sequential support that I have had to cripple for now.

It really depends on how they are planning to use the files.

What I ended up doing is putting a buffer arround the read(), write(),
close(), and lseek() calls that attempts to read and write the records

This also allows me to short circuit redundant lseek() calls as a small
performance boost.

It works for small text files, but not for large ones.  It turns out that NT
workstation does not always send a file in sequencial order.  For these
special record types, this will likely be a problem.

> 4. The stat and seek operations are done by reading
> the file! VERY bad performance.

There are other stat() issues with OpenVMS that hurt performance.  I need to
check additional security ACLs, and convert the times from local time to

> 5. The problem is exacerbated by the constant stating
> and seeking for no apparent reason.

I have not determined if the stat() calls can be eliminated, or how they
should be.  There is some logic that appears to be in a macro that is
supposed to eliminate some of the calls to stat().  I have not checked to
see if this is affecting performance for me.

> I am thinking of commenting out the stat and seek calls
> to see what happens.

I do not think that eliminating the stat() calls will work unless you can
somehow maintain the stat buffer between calls.

Commenting out the lseek() calls may be an issue when transfering a large
file.  I found that NT does not always send them the segments in the correct

wb8tyw at

More information about the samba-technical mailing list