So my flash drive died and I had to replace it. After I did, Mover seems to not run or do anything. I installed a fresh 4TB HDD that had been precleared, but every time I click to run Mover, it just refreshes the page and does nothing.

 

Thoughts?

 

diags posted just in case mediavault-diagnostics-20190420-1226.zip

• You appdata share is set to use cache:NO, which means that new files get written to the array (currently it exists on cache, disks 1&4).  (And also mover will never touch it)  Probably want to set it to use cache:Prefer
• Domains share is the same as above, but files currently only exist on the cache drive
• ISO's share is the same, but files exist on cache, disks 1&3
• System share: ditto with cache, disk1

 

5 minutes ago, Squid said:

• You appdata share is set to use cache:NO, which means that new files get written to the array (currently it exists on cache, disks 1&4).  (And also mover will never touch it)  Probably want to set it to use cache:Prefer
• Domains share is the same as above, but files currently only exist on the cache drive
• ISO's share is the same, but files exist on cache, disks 1&3
• System share: ditto with cache, disk1

 

So these should all be set to cache:prefer? I was having issues originally with my cache drive filling up and then breaking my docker containers. However, these all seem like smaller system files and nothing that would take up 250gb.

 

Edit: all shares listed above have been set to cache:Prefer

Edited April 20, 20197 yr by Arcaeus

It all depends on where you want the data stored.  Initially, it looks like mover won't do anything, because your share's settings have mover set to do nothing

55 minutes ago, Squid said:

It all depends on where you want the data stored.  Initially, it looks like mover won't do anything, because your share's settings have mover set to do nothing

I'm just having all of my media data on the array, and the Downloads share go to the array directly. My thinking is that the only things I would want on the cache drive would be the appdata share, and any other system related shares. It has seemed to work well for me in the past to keep the cache drive as open as possible so if I'm transferring files from my main computer, it has the space to do so.

 

And shouldn't Mover also move files between the disks to balance the load out?

Edited April 20, 20197 yr by Arcaeus

2 hours ago, Arcaeus said:

And shouldn't Mover also move files between the disks to balance the load out?

No. And I have never heard any good argument for "balancing the load out".

 

Mover moves cache-yes shares from cache to array, and it moves cache-prefer shares from array to cache. It doesn't move anything else.

 

Also, it can't move open files, so you will have to disable docker and vm services in order to get it to move system, domains, and appdata to cache where they belong.

15 minutes ago, trurl said:

No. And I have never heard any good argument for "balancing the load out".

Hum so I've been gathering to drive one till fill up and the drive 2 and so on, my rationale is that only the drives with data will spin up is this flawed thinking? interested with any thoughts on that never too late to learn

13 minutes ago, trurl said:

I have never heard any good argument for "balancing the load out".

 

ok.  How about my philosophy:  I would always rather lose some than all in the case of exceeding the redundancy of my parity drives.   If I have 3 drives die simultaneously, I figure that Murphy would say that one of those would be the one that has all of my wife's pictures on it, so I always keep data scattered over all drives.  I could never understand why anyone would want say all episodes of a TV show stored on a single drive instead of being scattered throughout various drives.

 

Or alternatively, with 2 simultaneous streams happening, with the files balanced out, the odds are reasonably decent that the streams will come from different drives instead of the same drive, reducing thrashing. 

 

Hence why I use Most Free as the allocation method, and whenever I increase the size of a particular drive I manually move the files around.

 

To each their own  

I think you can definitely make arguments for putting some things on one drive and other things on another drive. But just putting random things on random drives to balance them out is just another way to gamble.

3 minutes ago, trurl said:

gamble

Gamble with what?

35 minutes ago, Squid said:

Gamble with what?

Which files are on which disks when you

1 hour ago, Squid said:

have 3 drives die simultaneously

 

 

1 hour ago, Squid said:

...always rather lose some than all...

To each their own.  I'll never convince you, and you'll never convince me.  But, I am convinced that I'm right  

Another way to gamble would be to put all your baby pictures on one disk, and take the odds that it would be the other disks that fail so you lose none of your baby pictures.

On 4/20/2019 at 2:48 PM, trurl said:

No. And I have never heard any good argument for "balancing the load out".

Well, this may come back to bite ya. Yes, there could be reasons to 'balance the load out'. I know this is 3 years old, but I was looking up another issue for clearing out my cache disk and wiping/formatting to XFS from BTRFS and while that's happening this comment caught my eye.

 

I could sit here and say the same thing, in a sense. "I have never heard any good argument for *not* "balancing the load out"".

 

I suppose on a technical level, without having much understanding about how the UnRAID FUSE FS works under the hood, sure. Maybe its fine to frontload a bunch of drives with data and default to a high-water setup. But from an end user perspective (read: optics), it gives a sense of comfort in knowing that your disks are being used efficiently. Even if you and I know it doesn't mean that on the technical side.

Edited February 6, 20224 yr by jaylo123

On 2/5/2022 at 11:01 PM, jaylo123 said:

Maybe its fine to frontload a bunch of drives with data and default to a high-water setup. But from an end user perspective (read: optics), it gives a sense of comfort in knowing that your disks are being used efficiently. Even if you and I know it doesn't mean that on the technical side.

I would argue that is not a good argument. And there are very good reasons for NOT using Most Free allocation.

On 2/8/2022 at 7:22 AM, trurl said:

I would argue that is not a good argument. And there are very good reasons for NOT using Most Free allocation.

Yea. I can see both sides certainly!