stat (AGAIN!)

John E. Malmberg wb8tyw at qsl.net
Fri Mar 21 03:55:17 GMT 2003


"Peter Smode" <psmode at kitsnet.vancouver.bc.ca> wrote:

> I'm currently coding the change to get SAMBA to use RMS calls and FIDs to
> replace the primary call to stat(). The easiest way would be to have
> vms_opendir invoke a modified form of vms_stat to populate the cache while
> all the data required by the RMS calls were handy (i.e. the FID, DID and
> volume label).
<snip>
I do not know if the 2.2.x branch of SAMBA is using the VFS interface, 
but the 3.0 is.

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.

The VFS or Virtual File System interface makes what you are doing work 
much better with SAMBA.  With this design, wrapper code for UNIX 
filenames, or the requirement for ODS-5 is eliminated for all of SAMBA 
except for the files that are served.

This means that the routines that SAMBA uses for it's local files or 
housekeeping do not have to interfere with any caching that is needed 
for the files that are served.

I am falling out of touch with the direct SAMBA code, but one of the 
weaknesses that I have reported to this list before is that in the 2.0.x 
branch that SAMBA keeps doing the same look ups over and over again on 
the same file.  If SAMBA could do this lookup just once, and track a 
pointer to the structure until it was done with the file, I think it 
would help speed things up for both UNIX and OpenVMS.  But I did not 
have time to investigate how to implement it.

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.

There have been some ideas floated around for the a future version of 
SAMBA (4.0?) on the SAMBA-TECHNICAL list.  Because UNIX does not have 
the async I/O capability of OpenVMS, they are looking at actually moving 
some of the funtions into the Kernel.  Depending on how this is done, it 
could make an OpenVMS port even better, or it could make things worse.

The asynchronous I/O ability allows OpenVMS programmers to do things 
that for UNIX requires kernel hacking, so this is an opportunity to be 
able to get an OpenVMS port of an open-source project to be release at 
the same time as the UNIX version.  Because if we are not working on the 
current development version, it is harder to get fixes accepted in the 
main code stream.

And I will repeat this again, if there are functions that you need from 
OpenVMS, either special ones like directory change notification, or 
specific UNIX routines that are not yet in the CRTL, please let HP know 
through the official channels, and help with a case describing why the 
function is needed.  This is what helps determine what gets done first 
or at all.  There are a lot of nice things that Engineering wants to do, 
but what customers want will be given more weight than what internal 
engineers think might be a good idea.


-John
wb8twy at qsl.network
Personal Opinion Only




More information about the samba-vms mailing list