-Daedalus

+1 If it would cause too much problems, maybe each disk could be assigned an alias, keeping the original /mnt/disk mountpoint, and giving an option in the UI for displaying mountpoint name or alias.

As to your first problem, this is a known issue with RC2. Manually spin up your drives (even if they're already spun up, from what I understand) by clicking the little status LED symbol on the left. The temperatures should display correctly after this.

I completely forgot you can do this through the UI now. Ignore my first post.

Just to be clear here: Pinned != isolated. They're different things. Pinned just means a CPU core that a VM can use, but anything else can also use that core as well if it's free. This is done by pinning the CPU core in the GUI. Isolating a CPU core means unRAID doesn't touch it. This is done by appending "isolcpus="x,y,z" to your syslinux config on Flash > Main. If you want to fully isolate the cores so that only the VM uses them, then you'll need to change your syslinux config from this: To this (for example):

Valid points all. I hadn't considered the fact that no-one has written a plug-in for it yet. That likely does say something to all this. And you're right; I hadn't considered that some people use disk shares/mappings either. I guess we're at the same point: Feature request made, wait and see.

I have to disagree. unRAID is being billed as an appliance that gives you enterprise features for less money, and does lots of things without requiring as much user knowledge as a home-spun setup using a more common distro. If you're saying a regular user should be totally ok with using the terminal zero a drive with dd, then you're kind of missing the point. I could actually see this saving time, in the sense that a user kicks off the drain operation, then comes back a day or two later, can restart the array at a more convenient time, and yank the drive. Ho

I'm not ephigenie, but I liked the idea, so I'll give my two cents on it, for what it's worth: Maybe something like a broad strokes roadmap. Nothing too concrete, but even a post with headings like: Features being worked on for the next major/minor release (multiple cache pools) Bugs being squashed for the next major/minor release (SSD write amplification) Future possibilities currently under investigation (ZFS) You could make the forum visible to community developers only. Or if you're feeling particularly transparent, forum members with enough pos

This is why I don't comment much; I manage to completely miss the obvious most of the time. Reasoning for not including drivers off the bat makes complete sense now, carry on.

Fair point! I might have to pick up one of these to test with. I had no idea they existed, cheers.

Without going near any of the other stuff, I'm curious to hear your thoughts on this one: Why the concern over install size? Most people are installing unRAID on 16-32GB sticks these days. Does it matter much if the install size is 400 vs 100MB? I can absolutely understand efficiency standpoint; it's a lot of space for something very niche, I'm just not sure what the downside is. The only one I can really think of is longer backup times of the flash drive, but that seems very minor. Is there something I'm missing here?

Interesting. I didn't thing GPU drivers were coming this soon. I assume you didn't build in support for 3rd party modules just for that though, interested to see what comes of this down the road!

+1

What utility are you guys using for those stats?

+1

I don't have an answer to this, but try doing the same things with top/htop open. If you still see high CPU usage there, then there might be something up. If you don't, it's because the dashboard CPU takes iowait into account, which can spike if the CPU is waiting on disks. Obligatory feature request for iowait to be removed from dashboard CPU usage. This isn't the first time it's caused confusion. It really shouldn't be there. If it is going to be there, don't call it "CPU".

While this is true, it's somewhat irrelevant. The point of good UX is that you shouldn't have to ask where something is if you can't intuitively find it.

+1. I was amazed when this didn't happen the first time I saw one.

My bad. I misread your first post as "Emby". Never mind!

+1 My eyesight isn't great, and I also hate that colour combo.

Is there not an option to store this metadata on a separate drive? You could grab a 120GB drive for maybe $20 or something and throw all the images and the like on that. To me this sounds like quite a rare use-case, as most media front-ends have options to store metadata on a different path for exactly this reason. Still, an interesting request.

+1 Server management interfaces have a similar function for updating firmware or changing BIOS settings. Usually done by an "Install" button, or an "Install on next reboot" option.

+1 from me as well.

That's not a bad idea actually. When creating a user, maybe there's an option for "Create personal share for this user" User "bob" is created, share "bob" which is private by default, with only "bob" having r/w access. +1

Yeah, I remember bonienl saying this was fixed in the next 6.9 beta. (I remember because this one bugs the hell out of me on 6.8.3. 😋)

I would be nice if we could have a per-pool or per-array temperature setting. It seems like that would probably satisfy most requirements. I get a similar thing at the moment with some M.2s I'm using with unassigned devices. Thankfully that one goes away with 6.9, so I didn't bother requesting it.