Beiträge von 4valor

Zitat von Adoby

Yet another simple test.

In windows, navigate to a shared folder with files.
Create a new folder there. Perhaps "test".
Right click a file and select cut.
Right click the new folder "test" and select paste file into folder.

(I'm a little rusty with windows, I hope that was correct or at least possible to follow.)

Is the paste operation instantaneous?

Has the file been moved? Does it only exist in the "test" folder?

Alles anzeigen

Ok, so I did a complete reinstall of OMV on my Rock64. I fully updated all packages with apt. I then performed this test, and it moves instantly, just as it does on my Pi3. Copying on the other hand is slow. I'm satisfied now that "moving" seems to be working correctly. It must have been something with my SMB config. Thanks million for your help.

Zitat von tkaiser

Why? Or lets better ask: is this file then existing twice after your 'move' operation? In both source and destination?

Pardon my wording, "moving" works as it should, as does "copying". My issue is the timing of the operations. Where on my Rpi3 a copy or moving of a file will be instantaneous on the same drive, the Rock64 is infinitely slower. My hypothesis is that for some reason, clients (and this includes Android devices, not just Win10) are able to detect the Rpi3's filesystem and copy/move natively, while with the Rock64, files seems to transfer over the network and back again, instead of doing it natively on the connected USB device.

Sorry for my poor wording, I am sure I am probably not using the correct technical terms. And thanks for your help. your insightful posts are the reason I upgraded to the ROCK64.

The following post explains the issue quite well:

Very slow speeds

No solution was found, other than using Freenas or a file explorer like midnight.

Thanks your help. I disagree with your conclusion though. I am using the exact same method to transfer files on both the Rock64 and Pi3. I map a single SMB share drive on Win10 which contains several folders. I than copy from one folder to the other. I have even attempted to copy and paste the same file within the same folder and still have the same issue.

I am using the Pi3 in the exact same way, I suspect there is something amiss with the way I have configured the shares or something.

Just did the test, if I rename a file, it will rename instantly on my ROCK64.

Thanks for the feedback! Yes, but I can't get over the fact that my RPI3 in comparison will moves files instantly. Like even to the extent of 15GB worth of files, it will just move them over in seconds. Whereas the Rock64 will takes more than 30 minutes for the same files.

It appears to me that for some reason Windows is able to determine that the Rpi3 files are on the same filesystem, but is unable to do so with the Rock64.

I'm starting to think it might be related to the older version of OMV I am using for the Rpi3.

Hi guys,

I've spent a day trying to solve this issue, but no joy unfortunately.
I've searched and searched, but not found an adequate solution.

Basically, I've installed the latest OMV on a Rock64 and set up my SMB shares.
I've created a single share (from a connected USB 3 drive).
The problem I am having is when I use Win10 to move files from one folder to the other on the exact same drive, instead of moving the file instantaneously, it appears to copy the file over the network, which takes ages.

For example, on Win10 I access the share and I move a 2GB file from "Folder 1" to "Folder 2" (in the same root dir) it will take about 2 minutes to copy.
This happens no matter what client I use, Windows, Android etc.

The plot twist is that I also have an old Rpi3 with OMV installed and guess what? The files transfer instantaneously! If it were not for this Rpi3 working flawlessly, I would just install midnight commander on my Rock64 or Winscp and be done with it. I am just puzzled why I am able to transfer files on the same drive flawlessly on the Rpi3, but not on my Rock64. My OMV settings appear to be identical.

Any ideas would be greatly appreciated.

Thanks!