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