Interesting issues with strict allocate and large files ...

Jeremy Allison jra at
Mon Aug 1 20:06:16 GMT 2005

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


More information about the samba-technical mailing list