aburgesser
-
Posts
23 -
Joined
-
Last visited
aburgesser's Achievements
Noob (1/14)
1
Reputation
-
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.
-
I was mostly asking about SMB behavior as less technically inclined users of my servers may execute a move between shares using SMB. It hammers the network, but moving files via explorer is their workflow. Getting other users to change behavior is typically not viable. I probably will continue to use Krusader. I find it a faster workflow than the Dynamix File Manager. I'll just need to be mindful of this behavior. I'll probably do cache to disk transfers to avoid the issue unless Mover of Fix Common Issues are extended to handle files orphaned on a cache. Edit: SMB behavior is a true move. Explorer interprets the two shares as not the same mount and defaults to a copy for drag and drop.
-
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.
-
Thanks itimpi. This behavior is a perfect example of what is documented. I now vaguely recall seeing advice to copy/delete over moving now, but it looks like the tutorials I view still uses move operations in Krusader. Doh! I guess I will need to be more mindful of this going forward. I wish there was some kind of mover invocation/behavior that would resolve files stranded on a cache pool. Yes, I could change cache settings of the destination temporarily, but a share can only have one cache pool so it fails as a general solution and requires further follow-up for full resolution. Will I also see this behavior if I do the move via SMB?
-
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.
-
Looking to reduce server power usage - Would remaking the server help?
aburgesser replied to Thelas's topic in Hardware
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
-
Support for mounting ext4 volumes with the casefold feature.
aburgesser replied to aburgesser's topic in Feature Requests
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 apologize for being on a lagging version. I have not allocated the down time to update yet. Conditions: Source share includes Disk 2 and has prefer cache set Destination share includes Disk 1 with no cache Use Krusader to transfer file(s) from the source share to the destination share Observed Behavior: Files are available in the destination share Files are located in source share's cache (along the expected path for the new share) Files are absent from the disks included in the destination share Mover does not appear to move the files from cache to Disk 1. Double checked with manual mover invocation though scheduler. Expected Behavior: Moved files in this scenario should eventually wind up on the included disks of the destination share. I see several options to realize this: When files are moved to a share that has "cache: no" set, files will expunged from the cache (once they are in an included disk). Alternatively, mover should review all cache pools for each share for these kinds of remnants. Related behavior (hypothesis only. no observation) What happens when a share with files in cache drops the cache pool? finarfin-diagnostics-20230926-2222.zip
-
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.
