NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Moves on new NAS much slower than old NAS
Greetings, 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 ...
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.
Hi,
"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."
As you have suggested, I tried mapping the entire volume, in my case this is called c, for example:
\\NAS_NETWORK_NAME\c
When moving files or folders between subdirectory shares under c, a copy/delete still occurs.
For example, if moving the contents of:
\\NAS_NETWORK_NAME\c\Music\
to:
\\NAS_NETWORK_NAME\c\Videos\
It seems that I am still misunderstanding something. Am I mapping the entire data volume incorrectly by mapping \\NAS_NETWORK_NAME\VOLUME_NAME ?
Thanks for your help!
Crash_HI wrote:
\\NAS_NETWORK_NAME\VOLUME_NAME ?
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.
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.
Sandshark wrote: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 :-)
StephenB wrote:
Crash_HI wrote:\\NAS_NETWORK_NAME\VOLUME_NAME ?
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.
Thanks
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
