Interesting issues with strict allocate and large files ...

[Richard Sharpe]

On Mon, 1 Aug 2005, Jeremy Allison wrote:

> On Mon, Aug 01, 2005 at 12:35:03PM -0700, Richard Sharpe wrote:
> > Hi,
> >
> > I recently came across an interesting problem with strict allocate and
> > large files ...
> >
> > Customer was copying a large file (more than 4GB) to a Samba-based server.
> > The first thing the client does is a TRANS2 SET_FILE_INFO SET_END_OF_FILE
> > setting it to whatever the size is (6BG in this case). The smbd then
> > starts writing 6GB of zeros.
> >
> > After 37 seconds, the client sends a HELLO.
> >
> > After another 37 seconds the client drops the connection when it hasn't
> > heard back.
> >
> > Thus, the copy fails because of strict allocate.
> >
> > It would seem that there is basically no way around this, since the smbd
> > is deep in the VFS writing zeros ...
> >
> > I am investigating what the issues are with turning off strict allocate,
> > but they likely involve losing info about when space is exhausted on a
> > drive/volume.
> >
> > Windows responds withing about half a second to the SET_END_OF_FILE
> > request, even for 6GB. It might be that Windows maintains an in-core count
> > of the space reservations made on the drive, or perhaps it actually does
> > allocate all that space for the file.
>
> This is an interesting one... Even if we checked the space available
> and returned "ok" if we found 6gb free then we might fail if another
> client is simultaneously doing the same.
>
> I don't see how they can respond within half a second, unless they
> just decremented an "available space" counter and are writing out
> in parallel. There's no way they've actually allocated that data :-).

Yes, that was my thinking as well. I wonder if there are any tools
available for Windows that allow me to explore what a file actually
occupies on DISK?

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