Samba + exFAT : how to avoid pre-allocating when copying big files?

[Jeremy Allison]

On Mon, Dec 07, 2020 at 12:58:08PM -0500, Joseph via samba-technical wrote:
>Thank you Jeremy for your answer.
>About your test, it seems the syntax might be 'seek' and not 'skip' (the
>former skips bytes on output, the latter skips on input, i.e. /dev/null),
>so I tried this:
>sudo dd if=/dev/zero of=test2 bs=1k count=1 seek=1M   # seek 1 million of
>1k blocks, i.e. 1 GB
>Do you confirm it's what you were talking about?
>And you're right, it takes a *long* time, meaning that the full file is
>written, to only write 1k at the end...

Yes, that's what I would expect for a filesystem without sparse
file support.

>I wonder why would the Windows Explorer client go to EOF first? Is there a
>way to see (on the Samba server) the log of *all* operations sent by a
>Samba client and received by the server, including file open, file seek,
>file close, etc.? So that we could see if there is a seek to
>position=2,000,000 when copying a 2GB file ?

Windows clients are trying to pre-allocate the space they're
going to need. Usually they'll create a file, then do a file
size allocation request for the size of file they will be
copying (with 'strict allocate = no' on Samba this has no
effect). The problem is Windows doesn't report ENOSPC if
a copy files in the middle - as on Windows servers ENOSPC
is reported on initial allocation.

Then they will write in chunks, as seen.

>More generally, do you have any idea about how we could avoid this annoying
>behaviour?

Use a different client. We can't control Windows client
behavior.

>So it would be interesting to find a solution to address this exFAT
>problem.

You need to use a filesystem that supports sparse files. ext4
is well supported.

>Would there be a trick, with maybe some clever use of a configuration Samba
>option, to avoid this issue?

No, not possible.

>Or maybe could the Samba server send infos when connecting with the Windows
>client saying that it should *not* seek to EOF to preallocate space?
>For example would there be an old version that prevents this to happen
>(protocol = SMB1 ?)
>
>Fingers crossed that we can find a nice solution :)

We don't control the Windows client code. Until Windows
gets open sourced there's nothing we can do here.

Don't use exFAT for this is the best advice I can give :-(.