I recently had a power supply failure on my old OS4 ReadyNAS Pro Pioneer RNDP600E and migrated my data to a ReadyNAS 626X RN626X00. It is connected to my Windows 10 computer via 10GbE as a SMB share. My maximum data transfer rate from the NAS to PC is about 240MB/s, which is much faster than the old NAS.
What I am noticing is that file or directory moves that used to be almost instantaneous are taking many times longer.
It does not seem to matter how I connect to the NAS, as I have tried the following:
\\IP_ADDRESS_OF_NAS\share
\\NAS_NETWORK_NAME\share
\\IP_ADDRESS_OF_NAS\c
\\NAS_NETWORK_NAME\c
\\IP_ADDRESS_OF_NAS\c mapped to drive letter
\\NAS_NETWORK_NAME\c mapped to drive letter
In some of these, it is doing a copy/delete, while in others it is moving the files, but at a rate of a few items a second rather than how it was previously capable of moving entire directories in a second or two.
This problem occurs even if files or directory is moved within the same share such as Music.
Am I connecting to the NAS incorrectly, or is there a setting that I may have missed?
Thanks for your consideration
Model: RN626X|ReadyNAS 626X – 6 Bays with Intel® Xeon® Quad-Core Server Processor
If you are moving between shares, OS-6 will do a copy-delete (due to the fact that the two shares are different BTRFS subvolumes). You can get faster speeds when mapping the entire data volume, and not just a share. Then it will usually do a true move, even across shares.
You can also get faster speeds by disabling "strict sync" in the advanced SMB settings for the share. Though some applications might misbehave when you do that.
I assume you were still on OS4.2.x on the Ultra. What you are experiencing, as @StephenB explained, is one of the differences caused by the BTRFS file system OS6 uses. This one can seem to be a negative, but there are also lots of positives. Shares are BTRFS sub-volumes, not just directories. You may want to re-think your share structure because of it. Unless you really need separate access control, make what was separate shares into directories within a share. Moving between directories within a share is still just as fast as with the EXT4 file system of OS4. From SSH, you can also use the cp command with the --reflink option to just copy the pointer to the file to a new share/directory, then delete the original, which is also much faster than copying the whole file. You probably won't want to do that all the time, but it can be useful when doing the initial housekeeping after moving to an OS6 system.
AFAIK, mapping the whole volume will help some, as the NAS will then do the mv as a copy/delete entirely internally rather than the PC doing a bucket-brigade over Ethernet. But even from SSH, I have not seen that a mv will automatically use the --reflink option for the copy part. The explanations I've seen as to why this is the default behavior in BTRFS vary, but the one that seems to make the most sense is that if you run out of metadata space while the cp is happening, the kernel doesn't know it and goes ahead with the rm, resulting in data loss.
AFAIK, mapping the whole volume will help some, as the NAS will then do the mv as a copy/delete entirely internally rather than the PC doing a bucket-brigade over Ethernet. But even from SSH, I have not seen that a mv will automatically use the --reflink option for the copy part. The explanations I've seen as to why this is the default behavior in BTRFS vary, but the one that seems to make the most sense is that if you run out of metadata space while the cp is happening, the kernel doesn't know it and goes ahead with the rm, resulting in data loss.
Interesting observation.
When doing significant housekeeping I did some tests years ago and found that using "mv" within SSH resulted in the correct behavior.
The "mv" is "nearly" instantanious even for rather large directories.
I am pretty cautious when I am doing this and make sure that everything is well backed up prior to a significant shuffle of data around.
The most interesting point will be what happens to the ReadyDR targets on the backup machine. I expect that the data will remain in the old snapshot in the old share but appear to have been deleted and will appear as new data in the destination share.
I do have one share that there are two ReadyDR targets (two seperate ReadyDR jobs) and when I created the second one I did in fact consume additional space on the ReadyDR backup machine (in this case a couple of TB of additional data) so it would appear that the individual ReadyDR targets are in fact independent.
I am definitely not an expert on BTRFS but these are the behaviors I see.
Definitely like the monthly snapshots which hang around essentially forever 🙂
That is the correct path, though you do need to use the NAS admin credentials.
I wasn't sure if you were doing this on the OS-6 NAS, since the default volume name there is data, not C.
Yes, I created the volume as c rather than data, since that was what was used on the old NAS. Still, moves on different sub directories under c are still hundreds of times slower than within any one subdirectory, which is why I assumed that I was still doing something wrong. I am using the NAS admin credentials.
AFAIK, mapping the whole volume will help some, as the NAS will then do the mv as a copy/delete entirely internally rather than the PC doing a bucket-brigade over Ethernet.
Ok, this seems to be what I am experiencing, so I think I understand the situation now. I will have to move the entire contents of the volume to a single share if I want to be able to do moves in the way that I am accustomed to, but hopefully that won't be necessary. Most of the reorganization that I need to do will be within any single share, but if that changes I know I may have to restructure the volume.
AFAIK, mapping the whole volume will help some, as the NAS will then do the mv as a copy/delete entirely internally rather than the PC doing a bucket-brigade over Ethernet.
Ok, this seems to be what I am experiencing, so I think I understand the situation now. I will have to move the entire contents of the volume to a single share if I want to be able to do moves in the way that I am accustomed to, but hopefully that won't be necessary. Most of the reorganization that I need to do will be within any single share, but if that changes I know I may have to restructure the volume.
You can also try copying/pasting the folders across shares via admin web ui, which I believe will be faster then doing it on the PC
