stat (AGAIN!)

[Peter Smode]

John,

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

<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.

> 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.
<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.


> 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! :)

> 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.
>
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.

> 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.
>

Technically speaking, I'm not currently a customer. However, I'll shoot a
line to my old TAM.


Peter
*****************
Peter Smode
Kitsilano Network Research
psmode at kitsnet.vancouver.bc.ca