Add ability to safely stop a manual move.

 

Perhaps change the "Move Now" button to say "Stop Move" while a move is in process.  Better yet, just add a second button that says "Stop Current Move" that will stop automatic moves also.

 

If this is too hard, at least make sure the cache disk documentation warns that large moves can take a VERY long time.  I'm clearing off disks to add to the array, so I'm in the middle of a 430GB cache disk move to my parity-protected user share.  My poor hard drives have been churning for the last 14 hours straight, with probably another 3 hours to go.  I would never have moved so much data at once if I'd known that the actual move from cache is no faster than a move directly to the array...

I just hope that before final-4.3, the config page allows for configurable move time (and since I talk about time: PLEASE PLEASE PLEASE NTP!!!).

 

As for the move taking long... well, sorry no offence but DUH!

What would be the point of using a cache drive if the actual write speed to the array was already fast?

 

Also, moving FROM cache TO array, shouldn't be faster than moving directly to the array (not over network), but exactly the same, why would the speed be any different? The point of the cache mechanism, is doing it transparently.

 

If you want to have control over this, either don't use cache drive for certain disks that you move big chunks of data or keep it on but still access the disk shares directly and thus bypass the cache mechanism. To me both of these things are stupid and I would choose the third choice: Let it do its stuff as long as it takes, since it actually gives you acceptable performance.

 

If you move very large amounts of data, I would suppose this is the initial populating of your array right? In that case you might just risk not using cache AND parity drive until everything is in place (this way you'll have normal write speed) and only after everything is in place assign parity and let it build once (and cache for future moves). This is what I did.

 

 

Let it do its stuff as long as it takes, since it actually gives you acceptable performance.

I'm in line with this. I don't think canceling a long move is a good idea.

Nor do I think it's worth the effort of putting this into a button.

If this is a real issue, you can login and kill the mover script directly.

 

What may need to happen is 'nicing' down the mv so that it does not take up too many cycles if other work is to be performed.

Add ability to safely stop a manual move.

 

Perhaps change the "Move Now" button to say "Stop Move" while a move is in process.  Better yet, just add a second button that says "Stop Current Move" that will stop automatic moves also.

 

If this is too hard, at least make sure the cache disk documentation warns that large moves can take a VERY long time.  I'm clearing off disks to add to the array, so I'm in the middle of a 430GB cache disk move to my parity-protected user share.  My poor hard drives have been churning for the last 14 hours straight, with probably another 3 hours to go.  I would never have moved so much data at once if I'd known that the actual move from cache is no faster than a move directly to the array...

 

You bring up a good point.  We have a lot of ideas about enhancing the cache drive & mover functionality, e.g., a "time limit" and/or "transfer limit" on how long it should run.  These won't get into the 4.3 final release though.

I just hope that before final-4.3, the config page allows for configurable move time (and since I talk about time: PLEASE PLEASE PLEASE NTP!!!).

 

The mover schedule is already configurable via the setting called "Mover schedule" on the Share page.

 

Also you'll be happy to know that NTP will appear in the next release.

if you used rsync as the mv then you could also limit the speed of the transfer

 

I generally use rsync with these parameters when I move files to USB drives.

 

    --bwlimit=KBPS          limit I/O bandwidth; KBytes per second

    --remove-sent-files    sent files/symlinks are removed from sender

 

Also you'll be happy to know that NTP will appear in the next release.

 

THANKS!

if you used rsync as the mv then you could also limit the speed of the transfer

 

I generally use rsync with these parameters when I move files to USB drives.

 

    --bwlimit=KBPS          limit I/O bandwidth; KBytes per second

    --remove-sent-files    sent files/symlinks are removed from sender

 

 

Can 'rsync' remove the source files after copying like 'mv' does?

that's what  --remove-sent-files does.

 

you forgot the "duh"

 

...maybe this is the place to ask Tom why the folders need to stay on cache disk?

 

 

eh no duh's for tom. He can't know everything. that might take away from the stuff we play with.

Besides, he's one of those rubber room guys..

Lock him up in a rubber room and he comes up with unRAID. LOL!!!!! 

sure

(he has humor after all - the forum is still open)

 

 

Always helps to keep a sense of humor 

 

The reason we used 'mv' is that I examined the code for 'mv' to find out if it does the right thing, which it seems to, that is:

a) It uses a "smart" algorithm to allocate a large buffer, depending on how big the files and RAM is.

b) It doesn't delete the source file until the target has been successfully copied.

c) It does the right thing if another process tries to open the file while it's being copied.

 

Probably rsync does this safely as well, and maybe even better, but I didn't look at the code to make sure.

 

The reason directories are not deleted is simply to avoid race conditions where you might be writing new files to a directory at the same time that the mover is trying to delete the directory.  Notice rsync doesn't remove directories either, probably for this exact reason.  But we'll fix this little nuisance in a future release.