Samba improvements needed

Richard Sharpe rsharpe at richardsharpe.com
Thu Sep 23 23:49:05 GMT 2004


On Thu, 23 Sep 2004, John E. Malmberg wrote:

> In article <1095951537.3981.64.camel at bgpc.dymaxion.ca>,
>   BG - Ben Armstrong <BArmstrong at dymaxion.ca> writes:
> > On Tue, 2004-09-21 at 08:32 -0500, John E. Malmberg wrote:
>
> >> And it is not preallocation that SAMBA is doing as noted below.
> >
> > Oh?  It sure looked like it ...
>
> If you look at it from stepping through the file create sequence in the SMBD
> program it does.
>
> >> The client does tell the SAMBA server how big to make the file, but not
> >> when VMS can do it efficiently.
> >>
> >> First it has the server open the file for write access, and then it uses
> >> ftruncate() or other means to extend it.  Most of these move the highwater
> >> mark of the file, unlike just allocating space.  And that means that the
> >> now empty file must be totally written to disk.
> >
> > What's the distinction between this and preallocation?  Is it that the
> > client does the file extending writes in small increments, whereas
> > preallocation would do it all at once?
>
> The issue is that the way that VMS is doing it now, is slightly more overhead
> than should be needed.
>
> First, the open/write creates an empty file.
>
> Second, the SAMBA requests that the empty file be extended to the size
> the client says the end file will have.
>
> This is done one of three ways, and I am not sure which method that
> SAMBA 2.2.8 is using.  Method A, moves the high water mark and allocates the
> space.  Method B, writes an empty file of that size.  Method C ignores the
> request.
>
> Third, the data is written to the file.
>
> By delaying the open until there is actual data to write or the client has
> specified the resulting size, then Method A can be used.

[Deleted all the rest of the context because I only wanted to reply to
this point.]

I do not think you can defer opening the file until there is data to write
because of the race that implies. If the file did not exist when the
NTCreate&X was processed, that may seem fine, but if a subsequent
NTCreate&X comes in with a conflicting share mode, that one may succeed
when it shouldn't, especially if it manages to write before you do.

Regards
-----
Richard Sharpe, rsharpe[at]richardsharpe.com, rsharpe[at]samba.org,
sharpe[at]ethereal.com, http://www.richardsharpe.com


More information about the samba-vms mailing list