taalas Posted September 15, 2019 Share Posted September 15, 2019 Hi! I would like to move some files from the cache drive (/mnt/cache/...) to the array. I tried to mv the files from /mnt/cache/(dir) to /mnt/user/share/(dir) and it seemed to work fine the next time the mover was invoked. Is this in any way problematic, since I faintly remember one should not write to /mnt/user/? That is inly a problem when copying from /mnt/diskn/ though, right? Thanks! Quote Link to comment
Squid Posted September 15, 2019 Share Posted September 15, 2019 26 minutes ago, taalas said: I tried to mv the files from /mnt/cache/(dir) to /mnt/user/share/(dir) and it seemed to work fine the next time the mover was invoked DON'T DO THIS if the net sharename/dir/file works out to be identical between the source and destination. You will corrupt the file Because you're issuing commands, you are effectively bypassing the share system which sets the use cache settings, include / exclude disks etc What was the problem when mover started? Quote Link to comment
taalas Posted September 15, 2019 Author Share Posted September 15, 2019 Thanks for answering Squid. As I said it seemed to work well. The files appeared as "Cache" after i moved them and were moved to a specific disk after the mover processed them. Just to make sure: if anything went wrong only the files I manually moved are in danger, correct? What I am trying to do is move files from a cache-disk only share (appdata in this case) to the array. Since they weren't part of the array to begin with I assumed moving them tu /mnt/user/(share) would be the correct way of letting the mover decide on which disk to put them... Quote Link to comment
itimpi Posted September 15, 2019 Share Posted September 15, 2019 Mv is NOT mover! Also any folders on / mnt/cache are part of /mnt/user (two different views of the same file. This is why you must NOT try something like: mv /mnt/cache/dirname /mnt/user/dirname as you end up trying to write the file to itself which can end up truncating it. If you MUST try something like that then use /mnt/user0 as the target as that excludes the cache disk from the User Share. Quote Link to comment
-Daedalus Posted September 15, 2019 Share Posted September 15, 2019 Correct. Basically, never mix user shares and disks. /mnt/cache -> /mnt/disk[x] is fine. /mnt/user/dir1 -> /mnt/user/dir2 is fine. "user" is an abstraction layer used by unRAID between the disks. It includes cache and disks. 1 Quote Link to comment
taalas Posted September 15, 2019 Author Share Posted September 15, 2019 (edited) @itimpi I do know that mv and the mover are not the same thing. As I said I moved the files (using mv) from /mnt/cache/ to /mnt/user/ and then the mover daemon moved it to an actual disk on the array. I now understand that this is not good. Hence the question: if files got damaged, does it only affect the files I moved? Is moving the files to /mnt/user0/ the correct way then when moving files directly on the server? Edited September 15, 2019 by taalas Quote Link to comment
Squid Posted September 15, 2019 Share Posted September 15, 2019 (edited) How about this. This is no "correct" way of doing this. Only an incorrect way Incorrect: from /mnt/cache/share/file to /mnt/user/share/file from /mnt/user/share/file to /mnt/user0/share/file from /mnt/diskX/share/file to /mnt/user/share/file In all of those cases, since effectively the source and destination are identical (1st and 3rd and a possibility on the 2nd), the file gets corrupted So what you are doing is "correct" However, be aware that since you're working from a command prompt, if you move from /mnt/user/share/file to /mnt/user/AnotherShare/file (where share is use cache yes and AnotherShare is use cache no), then the file now in destination AnotherShare is on the cache drive. This may be in violation of the useCache settings for the AnotherShare, and is due to you bypassing the system, and mover won't touch it. Edited September 15, 2019 by Squid Quote Link to comment
itimpi Posted September 15, 2019 Share Posted September 15, 2019 6 minutes ago, taalas said: @itimpi I do know that mv and the mover are not the same thing. As I said I moved the files (using mv) from /mnt/cache/ to /mnt/user/ and then the mover daemon moved it to an actual disk on the array. I now understand that this is not good. Hence the question: if files got damaged, does it only affect the files I moved? Is moving the files to /mnt/user0/ the correct way then when moving files directly on the server? If files get ‘damaged’ then it is reasonably obvious as this particular problem ends up being zero length. when moving files within the server it is recommended that both source and target reference physical drives (or both reference user shares) as this is always safe. It has the disadvantage that it bypasses the User Share system as you are specifying the target drive explicitly. The suggestion of using /mnt/user0 is a special case when moving from cache to array when you want the allocation method to be taken into account for placing the target files. Quote Link to comment
taalas Posted September 15, 2019 Author Share Posted September 15, 2019 Thanks everyone for clearing this up. To summarize: as I understand it is "safe" to move from /mnt/disk[n]/... to /mnt/disk[m]/... from /mnt/disk[n]/... to /mnt/cache/... (and vice versa) from /mnt/user/... to /mnt/user/... from /mnt/cache/... to /mnt/user0/... When doing this one should be aware that disk includes/excludes etc. could be overruled. If moving files in other ways they can end up being copied to the position they are already in, resulting in zero-length files. This only affects the files moved "incorrectly" not other files on the array. Would this (kind of) sum up what has been said? Quote Link to comment
itimpi Posted September 15, 2019 Share Posted September 15, 2019 That sounds about right 1 Quote Link to comment
Squid Posted September 15, 2019 Share Posted September 15, 2019 (edited) If you're curious, here is the bug report regarding this (even though it's not a bug since you're bypassing the system) Edited September 15, 2019 by Squid 1 Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.