_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.

Actually, forget I asked. I was going to say can't you just reformat it and then let parity rebuild the files, but I guess that would also rebuild the current filesystem type. Heh. Sorry about that.

Do you have any parity drives?

They're not already organized into a bunch of subfolders? Instead of trying to gather: \TV Shows\ instead gather: \TV Shows\The Simpsons\ \TV Shows\Futurama\ \TV Shows\Top Gear\ \TV Shows\Misfits\ etc., selecting a bunch of the child folders instead of the main one. That's what I was trying to say earlier. If you actually have tons of huge files in a single folder, well, I suppose you could temporarily put them into some temp subfolders like: \Movies\A to G\ \Movies\H to N\ \Movies\O to U\ \Movies\V to Z\ and try gathering just one or two of those at a time. Or something similar. The more fine-grained you get, the easier it should be to fill up a drive. Then after gathering you can just move them back out of the temp folders into their original folders. If you don't have enough space to put everything onto a single drive you can at least put big chunks of things together. That'll help stop it from having to fire up a handful of drives most of the time.

Probably just isn't enough room. Try selecting a subset of the child folders instead of just the main parent folder.

Ah, I see. Mine's nothing but a fileserver for me. I know it is capable of doing a lot more, but that's all I want out of it, and it does that well. Thanks.

Ah, ok. Well, unbalanced can help, but it isn't going to let you move more data than there is room for on the destination drive. You're going to have to do some juggling. Move some to disk 1, move some to disk 2, repeat as necessary. It'll be a little easier if you have things in some nested sub-folders that can be selected independently. But it isn't going to let you select one folder that contains 5 TB of stuff on disk 2 to move to disk 1 if you only have 4 TB free on disk 1. If the data is split between the two drives it will show you how much would have to be moved and whether or not there's enough space for that job, though. Mind if I ask why you're wanting to move away from unraid? Just curious. Been using it for years here and still like it a lot. I'm up to two parity drives and 10 data drives now.

Well, the question is, why do you need to move data around at all? You say you have three 16 TB drives, and one of them is parity. So you have 32 TB of usable space. What are your plans? You might not have to move data around at all. All depends what you want to do. Are you adding more disks to the existing three? Do you want to replace one of the three with a different larger drive? What you're planning on doing has a big effect one what you can actually do and what you actually may or may not need to do. Give us some more info.

It might not hurt trying to have Chat-GPT explain the web ui code. You could also give it your code, and have it suggest a fix to yours to get it to behave in a similar manner. It might not be good to rely on Chat-GPT for large chunks of code, but it can certainly be helpful in overcoming a roadblock.

Flash drives are cheap, and you're not going to wear it out.

How long have you waited for the reboot attempt to finish? Lots of things that can take a while to shut down before it reboots compared to a more typical computer.