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