So Im extremly confused why my samba file transfer is so slow that it is kind of unusable. It seems to be fast in the beginning and then becomes stuck or extremly slow so that it has to be reset. A similar approach with one RaspberryPi had worked for me in the past.
For the setup I have at least two RaspberryPi´s lets say
drive2. The drives are usb drives either formatted via ntfs or ext4 ranging from 2 to 6 TB. So in reality the RaspberryPi holds one or more USB-Mounted drives that are mounted via
mount /<device>/<identifier> <target_directory>. Then samba is configured to expose the drives to the network as:
[storage] path = <path_to_directory_containg_mountpoints> public = no browseable = yes writeable yes create mask = 0777 directory mask = 0777 valid user = <list of valid users>
and is started via
sudo /etc/init.d/samba start. I do have a similar config for
rasp2 so that both
rasp2 can expose the USB-Drives to the network and clients can mount to them. The whole principle could be compared to an homemade-NAS of RaspberryPi´s and external USB-Drives.
Now to the clients: The client simply mounts the drives he is interested in and in our case
sudo mount -t cifs //<RaspberryPi_IP>/storage/<mountpoint_for_drive1> <target_directory> -o user=<user_from_list_of_valid_users>,gid=<local_usergroup>,sid=<local_user> for each respectivly. All of them are in the local network.
The main problem with this approach is that the file transfer rates from
drive2 via the clients mountpoint are terrible. When I instaniate a file-transfer progress either with
mv -vi "drive1/file1" "drive2/" or
rsync -a --info=progress2 --remove-source-files "drive1/file1" "drive2/" the progress depends on the size of the file. If the file is small and under ~1.8M the file can be transfered with ease as I would expect it. If the file is bigger however it seems like nothing happens.
iotop shows the initial data transfer spike of
smbd and I guess the mount and then stalls to 0% and stays there for a long time before another such spike happens. So technically the file would be transfered even if those spikes are minutes away.
What I think it could be: Now a bit more speculative first of the network for small packages is not the problem: If I do a 64 bytes ping I get a constant ~0.3ms ping from either the RaspberryPi to the client or the client to the RaspberryPi. When I tried a few things it seemed like a restart (
sudo reboot of the RaspberryPi, then remounting and restarting samba ) would fix the problem for a certain amount of IO operations or minutes depending on the amount of concurrent IO operations before one of them stalls. Maybe this is also related to a
Resource temporarily unavailable error which I got a few times which is another problem I have with this setup. Sometimes the mountpoints take extremly long just to list them ( not especially via the
mount command ) but when I enter the directory that several drives mount to. I thought that those drives go to sleep ( sometimes I even think they go to sleep if I run a query over them, like
find . -type f [...] ) so I disabled their standby with
sudo /usr/bin/sdparm --clear=STANDBY /<device>/<identifier> however so far this hasn´t brought me the expected result. Another problem I thought was the culprit was a filesystem error. Due to me killing multiple rsync and mv instances which were too slow I may terminated one of them too early. So I run
sudo fsck /<device>/<identifier> for ext4 and
sudo ntfsfix for ntfs respectivly. One of the drives actually had a problem but the problems ( listing directories which mount drives being slow, data transfer being slow ) still remains even after letting
fsck repair it.
htop is sometimes shown to have one core of the RaspberryPi to use 100% for a few seconds until neither
htop show any expected response.
RaspberryPI OS is: Linux raspberrypi 4.14.34-v7+ #1110 SMP <time> armv7l GNU/linux Client can be windows or linux Samba on RaspberryPi is: ( `samba --version` ) Version 4.5.12-Debian
RaspberryPi using samba to mount drives is extremly slow to moves files from ( reading ).
Displaying mountpoints via ls takes very long and sometimes even terminated with
Resource temporarily unavailable.
( Maybe a seperate problem ) Drives go to sleep while IO-Operations are performed on them