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