Bug 6976 - Problems copying large (>100 MB) files to samba share on fat32 usb drive
Summary: Problems copying large (>100 MB) files to samba share on fat32 usb drive
Alias: None
Product: Samba 3.4
Classification: Unclassified
Component: File services (show other bugs)
Version: 3.4.3
Hardware: x64 Windows XP
: P3 normal
Target Milestone: ---
Assignee: Volker Lendecke
QA Contact: Samba QA Contact
Depends on:
Reported: 2009-12-08 14:09 UTC by Erik Haggstrom
Modified: 2020-12-22 02:53 UTC (History)
1 user (show)

See Also:

Trace (8.88 KB, application/octet-stream)
2009-12-08 14:26 UTC, Erik Haggstrom
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Erik Haggstrom 2009-12-08 14:09:20 UTC
I have setup a system to work as a NAS drive using Debian on standard amd64 hardware using a usb harddrive with a fat32 partition as the media.

I cannot copy big files onto this share. 
Explorer (WinXP) appears to hang for ~1 minute and then reports 
TITLE: "Error Copying File or Folder"
MESSAGE: "Cannot copy <filename>: The specified network name is no longer available."

> uname -a
Linux 2.6.26-2-amd64 #1 SMP Thu Nov 5 02:23:12 UTC 2009 x86_64 GNU/Linux

> smbstatus
Samba version 3.4.3-SerNet-Debian
Comment 1 Volker Lendecke 2009-12-08 14:13:59 UTC
Please upload a strace of the smbd process. I suspect that a syscall takes too long. To take that strace, please connect to the NAS box, look with smbstatus which process is responsible for your client, and then issue a

strace -ttT -o /tmp/smbd.trace -p <smbd-pid>

where "<smbd-pid>" is replaced with the numeric process id you found with smbstatus. Probably the last couple of hundred lines of the file /tmp/smbd.strace are sufficient. In a next step, we might ask you for a debug level 10 log, but in this first run, the strace will probably be most interesting.

Comment 2 Erik Haggstrom 2009-12-08 14:26:58 UTC
Created attachment 5067 [details]

Trace made with strace
Comment 3 Erik Haggstrom 2009-12-08 14:30:50 UTC
Last line of the trace is:

20:19:55.674192 ftruncate(28, 344209408 <unfinished ...>

It looks like ftruncate may be the problem.
I have seen some old posts about ftruncate on vfat.


I don't know if they are relevant?

Comment 4 Björn Jacke 2009-12-08 14:52:18 UTC
vfat does not support sparse files, afaik the kernel HAS to will up the file with zeroes it it's ftuncated to a given size. If the drive IO is slow this takes a ling time. I guess fallocate in the kernel vfs filesystem driver will never come. This problem is probably unfixable. Mounting with async option or a much more aggressive fs caching of the drive might be a workaround in your case.
Comment 5 Volker Lendecke 2009-12-08 14:56:54 UTC
Oh, this is not fixable? At least responding to the SMBecho requests when putting the ftruncate call into an async thread should give us a lot more time. Or do you have a different experience?

Comment 6 Erik Haggstrom 2009-12-08 15:01:51 UTC
Ok, but is there nothing samba can do to still keep the connection with the client computer. I can copy the files fine to a windows "server" sharing the same drive even if it is slow.

A slow drive/IO is hardly a reason to just stop talking to the client over the network. But then, the client might not be very well written and expect the ftruncate to be instant.
Comment 7 Erik Haggstrom 2009-12-08 15:06:20 UTC
Security is not anything I'm interested in for this drive, so overwriting with zeroes to erase the data is not necessary.

Maybe a flag to vfat when mounting to disable the zeroing could be a solution. I realise that this is not the right place for that suggestion. But do you have any comments?
Comment 8 Volker Lendecke 2009-12-08 15:07:58 UTC
I am very sorry to say that, but there is no quick fix for this. I am sure that this will come within the next months, but it is no quick solution possible except to write a VFS module that ignores that VFS call. This gives up a little bit of protocol correctness, but it will help your problem.

Would you be in the position to test such a VFS module?

Comment 9 Erik Haggstrom 2009-12-08 15:15:58 UTC
Yes, sure.

I assume that what the windows client is looking to do is to allocate the space for the file rather than fill it with zeroes.

Is there another call (other than ftruncate) to the fs in linux that can do that?
Comment 10 yuuki_ikeda 2013-09-27 02:54:26 UTC
Currently, I am also faced with this problem.
It is exactly the same state.

Server OS : CentOS 6.2 64bit
Samba Version : 3.6.17 (and tried 3.6.5, 4.0.9)
Use the 16GB USB MemoryStick, and allocating a shared folder in samba

This problem, Is there a chance of being fixed in future versions?

I'm sorry. 
Because I am not used to English, a text may be strange.
Comment 11 michael li 2018-07-03 07:24:20 UTC
Any update on this issue ?  I tried samba 4.7.x, still the same issue
Comment 12 Björn Jacke 2020-12-22 02:53:18 UTC
don't use FAT/VFAT, exFAT has a chance to be a better choice for USB harddrives (if the kernel driver improves), see https://lists.samba.org/archive/samba-technical/2020-December/136068.html