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

Jeremy Allison jra at samba.org
Mon Dec 7 17:10:17 UTC 2020


On Mon, Dec 07, 2020 at 11:23:05AM -0500, Joseph via samba-technical wrote:
>Hello,
>When sending a big file (for example 2 GB) from a Windows computer to a
>Linux computer (with Samba server), then:
>* if the destination FS is ext4, NTFS, no problem
>* if the destination FS is exfat, then there is a strange delay (~30
>seconds) during which the Windows Explorer waits, before actually copying
>the file
>It seems that the Samba server first "preallocates" the 2GB, before
>accepting to start the copy from Samba client.
>Thus, 2GB (of probably null bytes?) are first written, and then, the
>actual file is written.
>How to avoid this effect that doubles the number of gigabytes written and
>doubles the transfer time?
>
>I have already tried:
>
>    strict allocate = no
>
>without any success in the exfat case.
>
>Any idea?

This may not be a Samba issue. It may be the exFAT driver
in Linux that is allocating the space for position 'N' when
a process writes a byte at position 'N+1'.

I don't believe exFAT on Linux supports sparse
files.

https://unix.stackexchange.com/questions/506740/how-can-i-copy-sparse-files-from-a-ext4-file-system-to-an-exfat-file-system-and

So if the Windows client on copy first writes a byte
at EOF or some other position to pre-allocate space,
Samba does the write which causes the Linux exFAT
driver to do the allocation (slow).

For a filesystem that supports sparse files and
"strict allocate = no" then that write will only
allocate one block and leave the rest of that file
sparse.

You can test this by doing:

dd if=/dev/zero of=/file/on/exfat-drive bs=1K count=1 skip_bytes skip=2G

and if this takes a *very* long time, then it's
a driver problem not a Samba one.



More information about the samba-technical mailing list