stat (AGAIN!)

[John E. Malmberg]

Peter Smode wrote:
> 
> The 2.2.7a code I'm using employs the VFS interface. Whether it has changed
> in v3.x I do not know.

I think it has changed, but as I did not realize it had been brought 
back into the 2.2.x stream.  It was not in the 2.2.x stream the last 
time I did a build and reported the results on this mailing list.
> <snip>
> 
>>I would recommend that anyone that is actually doing coding subscribe to
>>the samba-technical list so that you can get an idea of what is going
>>on, and to start looking at building the 3.x branch of SAMBA.
>> 
> Sometimes this is like looking at an elephant though a microscope. But I do
> get your point.

Yes, the traffic goes in spurts, some times it will go for weeks with 
out a post, but lately there have been a flood of posts.

> <snip>
> What files would these be? I seem to be looking at only the "after VFS"
> code, so I have no point of reference to see the changes.

The SMB.CONF file, and the debuging logs.  Before the tdb structures, it 
was used for all the different files that the tdb replaced.  Going 
through all of the UNIX to VMS + ODS-2 file mangling for these files 
adds a lot of overhead.
> 
>>It is too late to influence any changes in the 2.2.x branch of SAMBA,
>>but if we can build a good case, we can get changes in the 3.x branch if
>>we can demonstrate that it helps the UNIX version also, either from
>>better code flow, or better performance.
> 
> <snip>
> I don't see how we can do that in this specific case. While reducing stat
> calls would be beneficial to both implementations, changing their
> implementation to use FIDs (inodes, if you will) is beneficial only to us
> VMS folks.  From what I understand, this implementation is not possible in
> Unix without some serious hacking. Even then, the result is slower
> performance than by just calling stat(). However, maybe there will be some
> allowances for us *Open*VMS folks if we demonstrate how big a difference
> this makes. I think it ironic that we could be seen as the odd ones when we
> would only be asking people to not make assumptions about file systems! :)

What I have been wanting to do is instead of them tracking a file 
pointer or a fileno, to track a generic structure pointer.  This pointer 
would allow the tracking and disposal of data that either RMS or stat 
would have returned.

In the 2.0.x stream, the SAMBA program was keeping track of things by 
the original filename, and reopening or calling stat() over and over 
again every time that it needed to do an operation in sequence.

The most obvious way of caching was not practical because of the 
frequent opens of smb.conf, the locking files, and optionally the 
debugging files.

> 
> Point taken. But hasn't Jean-Yves got some real work to do? :) Seriously
> though, we need to get there first. This reminds me of Oracle's efforts on
> their VMS port. For them to manage it, they strictly documented all and
> automated much of the patching effort. Last I heard, they do not have a
> concurrent VMS release, but they do manage it within a couple of weeks.
> Aside from overworking our French benefactor, perhaps some of us could put
> together a detailed porting guide. This guide could actually include some
> DCL, Perl or awk code if that is helpful. Once we have this completed, a
> port of whatever the current SAMBA development version was at that time
> could be carried out by several people. This porting guide idea will only
> work if it is centrally located and updated from the lessons learned from
> each porting effort.

I had been looking at doing such a guide and part of that is in my 
frontport documentation.

I did the SAMBA 2.0.6 port and my early start at the 2.x and 3.x ports 
set up using search lists, where I kept the UNIX code in it's own 
separate directory tree, and then a CMS directory, plus a work 
directory.  This allows quick updates, but keeps it easy to track what 
has been changed and what is under test.

Where I got bogged down is that I am looking at a way to automatically 
update the UNIX directory tree with each change that was checked in.
This would allow OpenVMS to join the SAMBA build farm.  By being a 
member of the build farm, if anyone checked in a change that broke the 
OpenVMS build, they would need to fix it.

The tool to do that is RSYNC, but RSYNC has proven to be harder to port 
than SAMBA because it needs to fork() too often.  As a side though, I 
have ended up with a TPU program that can convert many UNIX man pages 
into OpenVMS help files, and Runoff documents, and a DCL program that 
can create the config.h file for a given OpenVMS release.

Then I found that there was a PYTHON version of Rsync, but that the 
Python port was not operational.  Jean-Francois Pieronne has remedied 
that for the most part, but I am trying to make things better with it's 
build.  I hope to be testing pysnc soon.

-John
wb8tyw at qsl.network
Personal Opinion Only