aburgesser

Thanks Jorge. I was hoping there was a more generic solution to keeping a container well behaved. This does seem to be a container specific issue as I found a toggle for the issue between different workloads today.

I don't know the triggering change, but UHD H.265 10 bit encodes have started to make my unraid GUI and SMB become laggy, unresponsive, and time-out. This is new behavior that I've only noticed started last month+. It seems that 1080p still leaves the GUI and SMB working as expected. I have --cpu-shares=2 and --cap-add=SYS_NICE set. APP_NICENESS is set to 12. Encode uses the array as a source and a cache HHD (independent of the server SSD cache) as a destination. The server is running 7.1.4 I know I could pin away from core0 as a nuclear option, but I would rather not lose the encode performance. Please help.

You can use a watch folder for this, but are you sure you want to re-encode? You can remux those to a different container using mkvtoolnix and avoid generational losses.

Still looking for help with this. The configuration was working as I wanted before so I know it's not a completely unreasonable ask.

If you can ssh in, use the powerdown script. While a power cycle is more than you want, this will handle stopping the array.

In the past month or so, I've noticed that transcodes (via a handbrake container) on my server cause both the web GUI and SMB to become laggy, unresponsive, and time-out. The handbrake container previously had --cpu-shares=2 and APP_NICENESS set to 12. Looking for solutions I found that I should be setting --cap-add=SYS_NICE for niceness to work, so I did that and further bumped the niceness to 16. These steps had no apparent effect. I'm not aware of any setting/configuration I've modified that could cause these issues. The server is slightly overdue for an update (7.1.4). Any thoughts of how I could restore responsiveness while transcoding. I would rather avoid the nuclear route of denying handbrake the use of one of my CPU cores.

Unless you are at capacity, I would use the SSD as a secondary pool and back it's data up to the array. You don't compromise its write speed/features and you avoid exotic problems from an atypical configuration.

Ditto. I'm starting to wonder if I'm shadow banned. I can't even get acknowledgement, much less answers to my questions on the forums. Very disappointing when the community was one of the hyped features 5 years ago. Not hard stuff either. Things like "is this behavior expected" or if a proposed solution is worth trying.

No one publishes idle draw specs. Best you can do is see what people claim as idle power for different systems and/or apply rules of thumb. TDP would estimate max draw if it wasn't gamed so much. Neither Intel nor AMD is being reasonable with that spec anymore. The conventional wisdom is to slap an i3 on an ITX board if you want a power efficient Unraid box. There are more exotic solutions, but they will compromise on cost/convince/features.

Problem is you need the boot loader to be able to pull the GUID. LT has been resistant to calls for alternate binding (or even boot migration) for a while now. I would use the internal storage as a cache pool. If size is a concern, don't use it to cache the array shares, but instead host the appdata and system shares.

As always you need to declare use case. A 6700 can be quite a decent workhorse. If you can settle for the older Quick Sync, it will even transcode H264 and H265 (8-bit). I still think a 6300 is a fairly good Unraid CPU due to the ECC support. Just remember to drop the overclock for stability. 16 gb of RAM is serviceable until you want to run more than a bare bones VM. There are enough M.2 slots to run mirrored cache pools. A plus for redundancy. I've happily commissioned less capable systems myself.

Is it intended for Fix Common Problems to address files orphaned on a cache from a move between shares (https://docs.unraid.net/unraid-os/manual/troubleshooting/#mover-is-not-moving-files)? "Check for files stored within a cache pool that isn't allowed within a share's settings" implies it is, but it does not seem to catch such problems on my sever even when I set the plugin to always spin up disks for checks.

FYI, if you want to get really cheeky:

Haswell can support 10 series cards just fine. Looking at AoE2, it seems like it didn't have specific GPU requirements so any GPU you can pass through should be fine. I would troubleshoot your pass-through problems first. You will never get going if you can't get the GPU to the guest OS.

E5 systems are known to be moderately power hungry at idle. Newer hardware will typically be more power efficient. Honestly the jump from Sandy Bridge to Skylake will only save 10-30 W idle looking at references I see. Dropping the dGPU is an easy win though. The 6500 is a die shrink and you will loose 2 cores migrating to it. It also offers (an old version of) Quick Sync for transcoding. Dropping the dGPU and using a iGPU for live encoding would further reduce power needs. Keep in mind that Nvidia hardware encoding was typically better quality than Intel's for a given year. You may notice a drop in quality. In addition to loosing 8 threads, you will also need to drop ECC moving to the 6500. You may notice less horsepower if you do migrate. Honestly, if you are married to Skylake, I would give a look at finding a 6300. That gen was weird since the i3 cannibalized the low end Xeon market.

Critical question is does he want to do live transcoding with Plex. Live transcoding is best done with some kind of hardware support (which is still improving every generation). A newer system also allows more resources to handle scope creep. However new rack mount systems get pricey fast. Especially if you wind up with an SAS backplane. The described workload is NAS+Plex hosting. If they don't need live transcodes, anything in the past decade and a half can do that and a second hand server starts looking real appealing.

Need more specifics: Is this just a Plex host or is it also responsible for storage? How much storage? Do you need live transcoding? Regardless, this topic comes up regularly. Please do a search first. A good low effort starting place is a i3 Intel ITX system with no extension cards: Intel iGPUs have decent hardware transcoding ITX boards have less real estate to power

I was hoping for at least a negative response. It seems like this could be addressed by recompiling a custom kernel, but I am unfamiliar with the process (though tech proficient in general). Can anyone advise for/against such action? I would like this feature so I can mount an SD card formatted on the Steam Deck as an unassigned device. If someone knows of an alternate workflow that would realize this I would love to hear it.

I can confirm RGauld's findings. I also had Web GUI responsiveness issues that were resolved by (just) removing "Unraid Connect". I find myself wishing there was a disable plugin option now. I will probably keep it off this server since it is stuck behind a double NAT anyway. I don't see the value of the plugin if I can't remote connect.

It is not currently possible to mount an ext4-formatted volume with the casefold feature. This appears to be because the CONFIG_UNICODE flag is not enabled in the kernel configuration.

First off, apologies if this has been addressed. When I finally found an error to search for that appeared unique, I got no hits in the thread. I would like to mount a micro sd card formatted by the Steam Deck. This would allow me an easy way to read/write to it from my primary, Windows workstation. This use case rules out a reformat as a solution. When I try to mount the partition the plugin processes for a little bit, but when it completes the partition is not mounted and the mount button is still available. Turning on the Udev log I see the following: Jun 3 11:21:15 finarfin unassigned.devices: Partition found with the following attributes: serial_short='201606271856', device='/dev/sdj1', serial='Generic-_USB3.0_CRW-SD_201606271856-0:2', uuid='0a93b999-b1fa-4f02-ad29-230f6bb55249', part='1', disk='/dev/sdj', label='Generic- USB3.0_CRW-SD', disk_label='', fstype='ext4', mountpoint='/mnt/disks/Generic-_USB3.0_CRW-SD', luks='', pass_through='', mounted='', not_unmounted='', pool='', disable_mount='', target='', size='0', used='0', avail='0', owner='user', read_only='', shared='1', command='', user_command='', command_bg='', prog_name='', logfile='' Jun 3 11:21:15 finarfin unassigned.devices: Mounting partition 'sdj1' at mountpoint '/mnt/disks/Generic-_USB3.0_CRW-SD'... Jun 3 11:21:15 finarfin unassigned.devices: Mount cmd: /sbin/mount -t 'ext4' -o rw,noatime,nodiratime,nodev,nosuid '/dev/sdj1' '/mnt/disks/Generic-_USB3.0_CRW-SD' Jun 3 11:21:15 finarfin kernel: EXT4-fs (sdj1): Filesystem with casefold feature cannot be mounted without CONFIG_UNICODE Jun 3 11:21:18 finarfin unassigned.devices: Mount of 'sdj1' failed: 'mount: /mnt/disks/Generic-_USB3.0_CRW-SD: wrong fs type, bad option, bad superblock on /dev/sdj1, missing codepage or helper program, or other error. dmesg(1) may have more information after failed mount system call. ' Jun 3 11:21:18 finarfin unassigned.devices: Partition 'Generic- USB3.0_CRW-SD' cannot be mounted. It looks like the casefold feature is the is the root cause of the failure, but I am not familiar with it. A casual google search suggests that CONFIG_UNICODE is a kernel flag that needs to be enabled. Can someone confirm or correct my analysis? Do I need to open an Unraid feature request to address this?

Sweating DGPU efficiency for an E5 system is putting the cart before the horse, no? If you want the best best possible DGPU HW transcoding, pick the cheapest SKU of the latest gen of your preferred flavor. HW transcoding improves in quality every generation, but does not improve with a bigger chip. The smallest possible chip with the support will probably be most power efficient. If you want to prioritize power efficiency over quality, do some research or switch to an IGPU. If you already transcode your library for space savings, you may not need HW transcoding. I find I really need to crush the stream bitrate before I trigger transcoding on my server. Alternatively, an E5 should have enough power to real-time encode a pair of streams on its own.

Energy efficiency is often in opposition with power, and is affected by several factors: Workload: all else being equal doing more will take more power. Especially long running/frequent workloads that stop the race to idle. Architecture: newer process nodes tend to have better efficiency metrics. Peripherals: any PCB not contributing to your use case detracts from efficiency. This applies to motherboards (ITX > mATX > ATX typically). Number and type of drives affects this. Also don't forget to run the server headless. Downtime: spin downs and scheduled sleep cycles will reduce power needs at the cost of availability. If you want a lazy route to a powerful server that is fairly efficient: Workstation ITX motherboard with Intel I3/Xeon CPU (IGPU for HW transcoding) of recent architecture No expansion cards 16-32 GB RAM 1 NVME cache drive, 1 parity drive, 2-4 array drives. Array drives should be 5400 RPM class. If you want to take it a step further you need some uncommon components. There is a community somewhere on reddit that tracks low power Unraid builds.

I would appreciate a second opinion before I throw together some hardware... My father recently passed. While he was ill, his NAS fell into disrepair (RAID has some bad SAS disks, it's unclear ATM if the array is lost; I want a offload target ready before I attempt data recovery). I am going to scavenge some of his unused hardware (with some new hard drives) to make a more appropriate sized, URAID based, NAS/light server for my mother that I am confident in remote administration/troubleshooting. I would appreciate any perspective into pro/cons of the different hardware I may have overlooked. Here are the motherboard options (all have suitable processors, but I would need to boot them up to review CPU info. New server will run: Array 4 sealed WD enterprise 4 TB drives. Will repurpose an old SSD for cache. Considering 1-2 new 6+ TB drives for parity. SMB shares Backup target Plex for streaming to PC and media sticks on local wireless (no live transcode or external hosting for now) BD+DVD MakeMKV to Handbrake auto rip + (CPU) transcode I am thinking the Haswell motherboard is the better pick. It should run leaner, faster, support more drives, and has USB3. The only pro of the Xeon motherboards is ECC memory. Is there a scenario where that can outweigh the cons that come with those systems? Thank you for your time and consideration. ASUS Maximus VI GENE: Neutral probably has a i7-4770K (stock clock) 8 SATA, 1 M.2 Pro Better expected power efficiency than the Xeon systems DDR3 RAM (at least 16GB, probably 32) Most on board SATA ports USB3 a i7-4770 typically produces 3.5x the benchmark score of a X5000 processor. Con No ECC Supermicro X7DAL-E: Neutral 2 LGA 771 Xeon Processors (X5000 chipset) 6 SATA Pro FB DIMMs have ECC (IIRC) 24 GB RAM Con Power efficiency (65 nm + FB DIMMS) Supermicro branch population is weird. (2 channels only have 1 DIMM each) No onboard USB3 Intel S5000PSL: Neutral 2 LGA 771 Xeon Processors 6 SATA Pro FB DIMMs have ECC (IIRC) 32 GB RAM Con Power efficiency (65 nm + FB DIMMS) No onboard USB3 Buy a new motherboard: Neutral I have a spare 2124g Pro checks all the boxes Con Workstation Boards for the 2124g are harder to find these days. Would probably be $500 for board and RAM and the delay would adversely impact the schedule I have.