_Shorty

I think the only concern with --remove-source-files is you still need to remember to rm directories, as it doesn't delete those. It only deletes files.

If it were me, I'd take a wait and see approach. If you happen to run into performance problems using defaults then you can take measures to try to alleviate those problems. Organizing different things onto specific drives can help in situations where you're running into throughput problems from a single drive, for sure. And the split level setting can help you out if you do end up having to worry about such things. But if you never actually run into the issue then it probably isn't worth your time to worry about it and try to do something about something that isn't actually happening for you. I suppose there might be a case for just setting it up to avoid that situation from the get go, but I'm lazy. If it is working fine without me having to do anything, then that's good enough for me. If I run into problems then I'll do something about it. Everyone's different. Some like setting things up for the worst-case scenario straight away during initial setup. Maybe they've already got an idea of what the typical workloads will look like and they want to think ahead to avoid headaches down the road. I'm not sure if I'll ever run into performance bottlenecks, so I'm just waiting to see if it ever is an issue. If it never crops up, that's some good luck. If it does rear its head, I'll take some steps then.

When you select a parent folder, it contains a group of files of a certain total size. If a target drive does not contain enough space for that total size then it is excluded from being selected. You must select from further down the tree, reducing the total filesize of what is selected, such that it is smaller than any target drives to which you wish to move things. As for your goal of spreading things out as much as possible, I don't much see the point. It is arbitrary. And it is just going to cause you to need more drives spun up at the same time more often. You don't need to micromanage things to that degree. At most, you might want to group similar files onto the same drive, such as a particular parent folder. So when you watch certain TV shows only that one drive spins up. Or when you access all your pictures, that one drive is the only one that spins up. Things like that. Spreading out all your pictures over 10 drives so that whenever you browse them you have to wait until it spins up yet another drive doesn't make much sense. When you throw a new drive in, just let the system do what it does. There's no need to move a whole bunch of stuff around. Just let it be empty space that gets filled naturally. The system will favour it until such time as its usage catches up with the other drives. Which is fine. It works well. And it means that all your recent additions to the file pool will mostly end up on that drive, and thus when you access any of it the system only needs to spin up that one drive. Just let the system do what it does.

Don't take this as gold, since it is just from Chat-GPT and I haven't tried it, or even proofread it thoroughly: file attached SNIPPET-fnc_time_since_last_disk_access.sh

I don't think it ever worked. The post right above yours reports an issue that's been in it as long as I remember, and there are several reports of the same thing throughout this old thread. And that issue renders it useless. If it can't even do what it is supposed to do then there's no point to it.

Don't have a recent backup of the drive to compare with?

Get one as soon as I could, and just let it be without one in the meantime. There's been at least one occasion over the years where I've had this happen to me, and I had to wait until payday to snag a replacement. Some may not be comfortable with that, but no harm, no foul, as far as I'm concerned. I've got two parity drives so I'm still safe unless two more die at the same time.

Why not just take the dead one out and throw the replacement in? Then you just hit rebuild. Done. Not much point in the process you're undertaking, really.

No parity?!

Yeah, some of us have mentioned things like this for years now. I don't know why anyone still uses it. It clearly doesn't work properly, rendering it pointless to use.

Nope, I haven't touched my share settings since adding the cache years ago. All shares were set to use the cache and move to the array, and that's how I left it for years. And until what seems to me to be around the time I updated to v7 the cache had been used all the time. Every single share had cache usage turned off when I looked into this today. edit: Well, to be more accurate, yes, what you describe does indeed seem to be what happened. But the problem is that *I* didn't turn off cache usage for any shares. Now it makes more sense as to why my backup script from another machine seemed to be taking longer than usual lately. Cache was no longer in use.

I'd just recently noticed my cache was pretty full, and I don't think it has been moving since upgrading to v7. I took a look in my /boot/config/shares directory and saw a file in there for a share that I haven't had in probably two years. The share no longer exists, as it was just a temporary one created to troubleshoot something. After the troubleshooting had been completed I got rid of that share. But for whatever reason the config file remained in that directory. I stopped the array and deleted that file, restarted the array and tried starting the mover again. No dice. *grumble* "Alright, maybe I'll reboot, too." Did that, and when everything was back up I tried starting the mover. Worked again. Strange that the config file remained after deleting the temporary troubleshooting share. Nuking that did the trick, at least it did after rebooting, too. edit: Well, crap. Spoke too soon. It did move something around, as the cache drive now contains about 24 GB more data than before. But the mover finished and exited and all of my share files and directories are still there. All that stuff should've been moved to the hard drives. Now I *really* don't get what's going on. edit2: Hmm, strange. So, after removing that erroneous file and rebooting, when I came back to have another look a little while later there were some notifications from the Fix Common Problems plugin. It stated that there are some shares set to not use the cache but there are files on the cache that should belong to those shares. So I start looking at my shares settings page, and NONE of them are set to use the cache anymore. So it would seem something in the v7 upgrade process (or maybe even one of the earlier version upgrade processes) somehow changed my share settings. I turned the cache back on for all of them and now the mover is finally doing what it should be doing again. Yay!

Try deselecting the parent folders and expanding them so you can select the individual folders underneath. I believe it is looking for one drive with enough space for the entire parent folder, and that's too much data for any of your drives. But ignoring the parent folder will give it smaller child folders to work with. I bet it works just fine once you do that. Although you might also want to check into the issues it lists. Probably need to go into unRAID's Tools, New Permissions, and in the right-hand drop-down menu select All and then hit start. Once that finishes, go back to the unbalanced page and reload it so it re-reads file info. I've seen persistent issues that no longer exist if I don't reload.

Near as I can tell, this tool has never worked properly since release, and I'm amazed anyone is still trying to use it.

I could be wrong, but I don't think so. Start a move that should take ~15 minutes or something, close the window, and come back in 10 minutes and see if it is still going. I'd be surprised if it wasn't.