Drops in speed during moving or copying inside NAS

no, it's not normal, please tuneup your install

To be honest sometimes I see this as well, especially when moving large a file from one disk to another (SSD to HDD).

install MC ( midgnight Commander), and copy/move using it, RE: How to Upgrade with Raid1 and Portainer (Containers)?

If you recommend another tool, it means that SMB is not up to the task?

It's not really a solution, I don't want to use shell to move files, but File Explorer on my PC.

Quote from auanasgheps

I don't want to use shell to move files, but File Explorer on my PC.

According to Samba Wiki the performance improvement feature "Server-Side_Copy" is available since SAMBA version 4.1, but I'm not sure that "File Explorer on your PC" does make use of the feature. Its controlled by using "SMB2 FSCTL_SRV_COPYCHUNK request"
see note:

Limitations:

• The client must support, and issue SMB2 FSCTL_SRV_COPYCHUNK server-side copy requests.

Questions to understand your setup are:

• Have you enabled SMBv1 protocol in OMV?
• What software versions are used on client? (best to add this information to your signature too because this is relevant for any client related question!)

Quote from LMRig

OMV5 - moving it only between 2 folders on NAS

OMV5 is obsolete due to Debian 10 reached "security only fixes" stage. Debian won't release new SAMBA features.

First I'd recommend to upgrade to OMV6.

Second more details are required about the client used.

Quote from auanasgheps

If you recommend another tool, it means that SMB is not up to the task?

no, that is not my point, i agree that SMB needs some tune, but a really easy workarround is to use MC for internal copy/move on the same RAID

Quote from auanasgheps

It's not really a solution, I don't want to use shell to move files, but File Explorer on my PC.

To use Explorer on your PC, try WinSCP, but because I think that bottleneck are something that involve the NIC, probably do not solve the culprit.

Quote from mi-hol

According to Samba Wiki the performance improvement feature "Server-Side_Copy" is available since SAMBA version 4.1

Server-side copying already happens since a lot of time. My network activity is close to zero when I move a file within the NAS.

Quote from mi-hol

I'm not sure that "File Explorer on your PC" does make use of the feature.

yes it does:

Clients making use of server-side copy support, such as Windows Server 2012 and Windows 8, can experience considerable performance improvements

I'm using Windows 10 (21H2).

Quote from mi-hol

Have you enabled SMBv1 protocol in OMV?

For the love of god, please, no.

I am actually enforcing: min protocol = SMB2_10

Quote from mi-hol

What software versions are used on client?

Using Windows 10 21H2, means I'm getting the latest and greatest SMB versions. I also have a Windows 11 client.

If I run Get-SmbConnection, my shares show up as SMB 3.1.1.

Make it extra clear: when I transfer a big file, speed is good and almost maxes out my hard drives write speed. However, during the transfer, speed can fall almost to 0, then it goes back up. It does not fluctuate as much as OP, it only happens 2-3 times during a large file transfer.

I'm sure is related to Samba and how it manages writes. I am using MergerFS, but since we are talking about just one big file, it does not matter as it is being written to just one HDD.

I am using stock OMV SMB settings, plus the following:

min protocol = SMB2_10
mangled names=no
access based share enum = yes
hide unreadable = yes

Here's an example: average speed was pretty good around 150/160 MB/s, but there's a clear dip that took some time to recover.

UPDATE!

Easy peasy fix for me.

I have to admit I always ignored Samba Optimization threads, because they commonly target low powered machines with speed problems. My server at first glance maxes out 1 GB/s and I don't lack computing power.

I also observed that many recommendations are deprecated, not relevant, do not follow best practices or simply specify... the default value.

However, these settings actually make the difference on systems like mine, even if hits only 25% CPU utilization during a F A T file transfer.

read raw = yes
write raw = yes

getwd cache = yes # IT IS ALREADY ENABLED BY DEFAULT, do not bother with this.

I am now maxing out my HDD write speed and there are no dips or interruptions whatsoever!

LMRig please try and let me know.

EDIT: According to the official documentation, getwd cache is already enabled by default. Now you understand why I don't trust random dudes on the web who tell to enable this and that...

EDIT2: YES it is enabled by default indeed.

I removed the option, then ran testparm -v which shows all of your settings + defaults. The option is enabled.

So you only need

read raw = yes
write raw = yes

EDIT3: Apparently read raw and write raw are also default settings, but they truly make a difference when explicitly enabled. I'm not sure why, can somebody explain?

Quote from votdev

According to https://www.samba.org/samba/do…/man-html/smb.conf.5.html both options are enabled by default.

Yeah I eventually figured this out too, but it seems that they are are actually improving performance. It doesn't make sense, so I'll do more testing soon.

Do you agree that if an option is not specified in the main configuration but is enabled by default according to SMB documentation, is actually enabled?

In a test VM I get Yes, so it should be. I'll do actual testing soon.

root@omv6:~# testparm --parameter-name="write raw"
Load smb config files from /etc/samba/smb.conf
Loaded services file OK.
Weak crypto is allowed
Press enter to see a dump of your service definitions


Yes

After further testing, I can confirm that there's no difference with and without them.

Sometimes a transfer goes pretty smooth, but most of the times I still have the dips I was talking about.

So the logic of SMB seems fine, but I still haven't found what setting can make it better.

Quote from auanasgheps

I am using stock OMV SMB settings, plus the following:
Code min protocol = SMB2_10

that is a great decision

From the other details provided a simple software related root cause can be ruled out.

In the past network hardware was often the root cause in other cases.
Mainly cable connections and WLAN routers with single core processors.

Could you please elaborate on the network equipment and topology used?

Quote from mi-hol

that is a great decision

From the other details provided a simple software related root cause can be ruled out.

In the past network hardware was often the root cause in other cases.
Mainly cable connections and WLAN routers with single core processors.

Could you please elaborate on the network equipment and topology used?

I get the same issue both in PC to NAS transfers and NAS to NAS transfers, so my network doesn't really matter.
Still, I am using a Asus RT-AC86U as router, my NAS and PC are both connected with CAT6 cables at 1GB/s. The router has plenty of horsepower!

I still believe there's something going wrong with SMB itself, because this issue also happens If I copy from/to the NVMe SSD on the NAS.

Have you tried FTP?