RaspberryPi samba file transfer is extremly slow

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
0
down vote

favorite












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 rasp1 and rasp2. Then rasp1 mounts drive1 and rasp2 mounts 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 rasp1 and 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 drive1 and drive2 via 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 drive1 to 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 iotop nor 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


TL;DR:



  • 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







share|improve this question



















  • Why samba? Use nfs between 2 linuxes!
    – Ipor Sircer
    Jun 21 at 15:40










  • @IporSircer I actually haven´t used nfs in the past. The one and only reason for samba was that I do have a windows client.
    – What
    Jun 21 at 15:44











  • The time is now.
    – Ipor Sircer
    Jun 21 at 16:06










  • It almost sounds like that 'ole swapiness issue starving apps out of memory during long file transfers. With old kernels there was an issue with CIFS shares that a gigabit card performed like a 10Mbit card, and it could be addressed with mount options, but it has been fixed in 4.x series kernels, but swapiness remains.
    – ajeh
    Jun 21 at 16:18














up vote
0
down vote

favorite












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 rasp1 and rasp2. Then rasp1 mounts drive1 and rasp2 mounts 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 rasp1 and 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 drive1 and drive2 via 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 drive1 to 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 iotop nor 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


TL;DR:



  • 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







share|improve this question



















  • Why samba? Use nfs between 2 linuxes!
    – Ipor Sircer
    Jun 21 at 15:40










  • @IporSircer I actually haven´t used nfs in the past. The one and only reason for samba was that I do have a windows client.
    – What
    Jun 21 at 15:44











  • The time is now.
    – Ipor Sircer
    Jun 21 at 16:06










  • It almost sounds like that 'ole swapiness issue starving apps out of memory during long file transfers. With old kernels there was an issue with CIFS shares that a gigabit card performed like a 10Mbit card, and it could be addressed with mount options, but it has been fixed in 4.x series kernels, but swapiness remains.
    – ajeh
    Jun 21 at 16:18












up vote
0
down vote

favorite









up vote
0
down vote

favorite











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 rasp1 and rasp2. Then rasp1 mounts drive1 and rasp2 mounts 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 rasp1 and 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 drive1 and drive2 via 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 drive1 to 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 iotop nor 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


TL;DR:



  • 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







share|improve this question











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 rasp1 and rasp2. Then rasp1 mounts drive1 and rasp2 mounts 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 rasp1 and 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 drive1 and drive2 via 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 drive1 to 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 iotop nor 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


TL;DR:



  • 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









share|improve this question










share|improve this question




share|improve this question









asked Jun 21 at 15:36









What

113




113











  • Why samba? Use nfs between 2 linuxes!
    – Ipor Sircer
    Jun 21 at 15:40










  • @IporSircer I actually haven´t used nfs in the past. The one and only reason for samba was that I do have a windows client.
    – What
    Jun 21 at 15:44











  • The time is now.
    – Ipor Sircer
    Jun 21 at 16:06










  • It almost sounds like that 'ole swapiness issue starving apps out of memory during long file transfers. With old kernels there was an issue with CIFS shares that a gigabit card performed like a 10Mbit card, and it could be addressed with mount options, but it has been fixed in 4.x series kernels, but swapiness remains.
    – ajeh
    Jun 21 at 16:18
















  • Why samba? Use nfs between 2 linuxes!
    – Ipor Sircer
    Jun 21 at 15:40










  • @IporSircer I actually haven´t used nfs in the past. The one and only reason for samba was that I do have a windows client.
    – What
    Jun 21 at 15:44











  • The time is now.
    – Ipor Sircer
    Jun 21 at 16:06










  • It almost sounds like that 'ole swapiness issue starving apps out of memory during long file transfers. With old kernels there was an issue with CIFS shares that a gigabit card performed like a 10Mbit card, and it could be addressed with mount options, but it has been fixed in 4.x series kernels, but swapiness remains.
    – ajeh
    Jun 21 at 16:18















Why samba? Use nfs between 2 linuxes!
– Ipor Sircer
Jun 21 at 15:40




Why samba? Use nfs between 2 linuxes!
– Ipor Sircer
Jun 21 at 15:40












@IporSircer I actually haven´t used nfs in the past. The one and only reason for samba was that I do have a windows client.
– What
Jun 21 at 15:44





@IporSircer I actually haven´t used nfs in the past. The one and only reason for samba was that I do have a windows client.
– What
Jun 21 at 15:44













The time is now.
– Ipor Sircer
Jun 21 at 16:06




The time is now.
– Ipor Sircer
Jun 21 at 16:06












It almost sounds like that 'ole swapiness issue starving apps out of memory during long file transfers. With old kernels there was an issue with CIFS shares that a gigabit card performed like a 10Mbit card, and it could be addressed with mount options, but it has been fixed in 4.x series kernels, but swapiness remains.
– ajeh
Jun 21 at 16:18




It almost sounds like that 'ole swapiness issue starving apps out of memory during long file transfers. With old kernels there was an issue with CIFS shares that a gigabit card performed like a 10Mbit card, and it could be addressed with mount options, but it has been fixed in 4.x series kernels, but swapiness remains.
– ajeh
Jun 21 at 16:18















active

oldest

votes











Your Answer







StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);








 

draft saved


draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f451132%2fraspberrypi-samba-file-transfer-is-extremly-slow%23new-answer', 'question_page');

);

Post as a guest



































active

oldest

votes













active

oldest

votes









active

oldest

votes






active

oldest

votes










 

draft saved


draft discarded


























 


draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f451132%2fraspberrypi-samba-file-transfer-is-extremly-slow%23new-answer', 'question_page');

);

Post as a guest













































































Popular posts from this blog

How to check contact read email or not when send email to Individual?

Displaying single band from multi-band raster using QGIS

How many registers does an x86_64 CPU actually have?