-Daedalus

Agreed. An implication of my feature request would be that the remainder of the parity would have to be checked at some point before the new disk is added. But I think on balance a bunch of parity reads one time - when a bigger data drive is added - is better than a bunch of parity reads at every parity check when you're not running big disks. As I say, just food for thought.

And I totally understand that, but I'd be curious to see how many people are in my situation. Most people (I'd guess) expand their storage relatively infrequently, and given SATA ports are finite, I go for the biggest, reasonably priced €/TB drive to expand, and usually more than one at once. This usually means I'm replacing parity first, and putting the previous parity drives in the array. In this case, even replacing two smaller drives, I came away with 12TB more storage, and the ability to add 18TB disks in future, instead of 10TB ones. This isn't huge on the priority list, obviously. I just thought I'd flag it, given that something like 40% of the check (3 days, with parity tuning) is wasted every month.

I have a mix of 4, 8, and 10TB data drives. I have two 18TB parity drives. Every month, 8TB of parity is needlessly checked. Is it possible to have parity finish at the 10TB mark?

One of mine I'm using at present. Fairly generic, but looks nice, and stuff at either side is easy to read.

+1! I have DHCP-res on my router, but I still forget. I have last octet in the VM description, but a dedicated column for the address would be lovely. Also as a side-request: The ability to resize, move, and order-by columns would be cool.

I know, just adding the +1 because the request was for support for this on the UI.

+1 I'd like this as well. Having an entire share just for logs is a little much I think.

Please yes. I'm rsyncing this at the moment, but I'd love a native option for it.

Absolutely, +1 At the moment I'm copying vdisks and making the config manually, but would be very nice to have this, especially when playing around with cluster setups.

+1 In line with the save/restore option, it would be nice if modules weren't so easy to move around. I've dragged a module to a random place when trying to highlight a piece of text more than once.

Well that's basically what I'm trying to do. The issue is that there's no path exposed within AMP to change the backup location, and because the backup location is inside each of the server instances that AMP is running, I can't just specify one for everything, hence my question on variables. As in, if the structure were: /amp/backups/server1 /amp/backups/server2 /amp/backups/server3 That would be fine. One extra path added, done. But, they're: /amp/server1/backups /amp/server2/backups /amp/server13backups So if I change the location for /amp to something cache:yes, then eventually all the system files for AMP get moved to HDDs as well.

That did it, nice one! I didn't realise those config files stayed around. I still had a bunch in there from your squidbait ransomware plugin ages ago!

Hi all, Bit of what might be an edge case here. I'm using AMP (App Management Panel) to host game servers. AMP is running on my NVME pool, with the appdata stored there as well, including all of the backup ZIPs for each server. I'd like to move these off of the NVME pool, and have them moved to the array by the mover. The problem being that I don't want anything else moved. As it stands at the moment, I need to add a path to the container each time a new server is added, I have to manually add a path as follows: /home/amp/.ampdata/instances/[server name]/Backups >>> /mnt/user/backup/amp/[servername] Is it possible to add something like: /home/amp/.ampdata/instances/*/Backups/ >>> /mnt/user/backup/amp/*/ As a path? Does it recognise wildcards or variables like that? The goal here is just to not have to manually create these mappings and restart all the game servers whenever I want to enable backups for a new one. It's not a huge deal, but it would be nice if there was a solve.

Just tried to name "cachealso" to "cache", after changing the unassigned device from "/mnt/disks/cache" to "/mnt/disks/temp". Same error. This almost seems like unRAID is reserving "cache" as a thing that can't be used. Is it actually a generic pool, or are there references to it somewhere that prevent it being named? Diags attached if helpful. Obviously it's not a critical issue, but it is weird. server-diagnostics-20211204-0817.zip

Nope, no user shares named cache. I do have an unassigned drive that's mounted on /mnt/disks/cache. I've renamed that, waiting for a parity rebuild to finish before I can stop the array to try the change again. I'm not sure why a UD mount would interfere with this though; it has nothing to do with unRAID core disks. Output of ls on /mnt and /mnt/user shows no cache directory. FWIW I checked all the container mappings as well (twice, just now and when I originally moved stuff as I had to remap it from /mnt/cache to /mnt/nvme) and none are using cache. Everything is either on nvme or cachealso.

Simple on here, I think: I had a single SSD cache storing everything. I installed two new NVME drives and moved my VMs and docker stuff to /mnt/nvme At the same time, I installed two new SSDs, and moved all the other things from cache to the new SSDs in /mnt/cachealso I now want to rename "cachealso" to "cache", but I get an error saying I can't use a share name, despite that fact that /mnt/cache does not existing on the server, or in any mapping anywhere. Am I missing something?

Nope. You can add any size disks you want to a pool, and unRAID will figure it out. I personally ran a pool of 1TB + 2x500GB disks no problem.

+1 I'm doing this manually at the moment, but it would be nice to have it built-in as a mover option.

I like this topic. I've edited your post a little to include some things. I for one would like to know where VM XML lives for example, and if the only things needed to restore VMs are the vDisks and XML.

Yours was the post I read! That explains that so, thanks!

So I just checked this after updating to 6.9.1 Two 9207-8i's on P16 firmware. All my SSDs TRIM fine, except for my 850 Evo. Something something zeros after discard? I remember reading this as a reason for issues with Samsung drives, can't find specifics at the moment though. Moved it to one of the motherboard ports and it TRIMs fine again. Haven't tried with P20 fw as of yet.

I figured I should post on AMP about this, except for the big warning on your Git page. I'll go do that, see what they come back with.