I have two routers with USB port that I have configured with OpenWrt, one has a Broadcom chipset and the other one a Marvell chipset. Both have Samba 3.6 installed and both have the following issue:
First, if I copy a larger file from the USB flash drive connected to the router to my Windows PC (i.e. read from the USB drive), everything is absolutely fine.
But if I copy a larger file from my Windows PC to the router's USB drive (i.e. write to the USB drive), then there is a delay before the actual copy process starts. The delay increases as the file size increases and is nearly as long as the ensuing copy process itself. During the delay period the USB drive's activity LED is flashing all the time, but there is no network traffic visible, neither in Luci's "Traffic" graphs, nor in Windows 10's task manager.
While I don't know what is actually happening there, it looks to me as if the router was kind of "simulating" a write of the file that is to be copied, before the actual copy process starts.
Has anyone else experienced this? Are there any settings I could adjust to get rid of that delay?
Yes, I see it on mine with larger files, it's never bothered me enough to keep track but I'm guessing it usually occurs on files larger than 5gb and can last for a minute or so, I'm not sure if there are settings to change or not unfortunately.
Sounds like a flash drive with reasonable read speeds but abysmal write speeds. Keep in mind the interface (is USB 2, USB 3) isn't the actual read speed, much less the write speed.
One usually needs to do thorough research or spend quite a bit of money to get a performant USB stick.
Writing any file is buffered in RAM, once there is no more space in RAM the write process stalls until the data can be accepted by the drive. This is the 'io' CPU time shown in
And yes the USB thumb drives that are either cheap or large capacity tend to be very slow to write.
Ok, I will try to explain again, although mike seems to have understood what I am getting at.
The speed of the flash drive I am using is not the issue. It's a 32GB SanDisk Extreme USB 3.0 that manages about 220 Megabyte/s sequential read and 95 Megabyte/s sequential write, formatted as FAT32.
Anyway, today I tried again with an old-fashioned 3.5" mechanical SATA-HDD inside an external case with USB 2.0 interface. This one I formatted as exFAT.
Both of my OpenWrt routers have USB 2.0 interfaces anyway.
With the external HDD connected to the router I am seeing the exact same issue as I mentioned in my original post.
Here is the story again in detail:
I open Windows Explorer and copy a file of (for example) about 1 GB in size from a local disk. Then I browse to the network share of my router to which the above mentioned external HDD is mounted to and paste that 1 GB file onto it. The Windows copy-progress window opens and the HDD starts showing activity, indicated by LED and the usual "whirring" noise. For the next 40 seconds the copy-progress window keeps showing 0% and "Calculating" and there is no outgoing network traffic from the Windows PC (about 30 KB of data during that whole period), all while the HDD on the router is busily working like there was no tomorrow. After those 40 seconds the copy-progress window eventually comes to life and shows the % going up and a copy speed of about 24 Megabyte/s. Now the graph of the network connection in the Task Manager also shows outgoing traffic, at a rate of about 200 Mbps. 43 Seconds later the copy process has finished, making it 1 min 23 sec in total.
The duration scales with file size. So for a 500 MB file the "delay" time is about 20 sec and the "copy" time about 22 sec (42 seconds total).
It looks to me as if the router was first physically checking if it’s possible to write a file of size X to the USB storage before accepting the actual data from the client. (?)
However, I have two other routers and a NAS with the original manufacturer's firmware on them, which I know are also Linux and Samba based, but they have no such write-delay issue.
Are you sure it is not the Windows client (the file explorer) who is delaying the transfer of data? Can you try to copy from a different OS that supports SMB? Or from a Windows client to a Windows server? I am not aware of Linux needing any "calculation" prior to creating large files.
I have a vague memory of something similar happening when Windows decided to check for copy-protected content or something similar.
This is a combination issue with the VFAT driver being slow (or, arguably, thorough) and the software used for copying. Windows Explorer, when copying a file, first asks the destination to pre-allocate the total size. To do that Samba calls ftruncate() ... which is really slow with FAT filesystems (I believe I remember it writes the whole file with zeroes first, which is not done with filesystems like ext4 that support sparse files).
It depends on the program that does the copying, though. Unlike Windows Explorer, some other file explorers do not call for this pre-allocation. And it's not inherently a bad thing, Windows Explorer is probably just trying to avoid copying data that will not fit in the end.
Google "samba vfat ftruncate" to find folks having the same problem for decades.
(Edited for clarity)
Thanks! This is very likely what is happening here.
I've just tried using xcopy from the Windows command prompt and it is the same.
However, if I copy a large file from my Android phone to the router's USB disk, then the copy process starts right away. (I see a constant flow of network traffic from start to finish)
Apparently there is no fix for this issue other than to format the USB disk to a Linux file system, which of course takes away the convinience of being able to use this disk on a Windows computer if needed.
If your problem is solved, please consider marking this topic as [Solved]. See How to mark a topic as [Solved] for a short how-to.
Thanks for the reminder. I seem to be unable to edit the topic title, though.
Btw, in case someone else is annoyed by the above discussed behavior and knows how to compile Samba for his/her platform (which I unfortunately don't), then they could consider the modification described at the end of the following thread:
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.