SinoBreizh

Thanks for your answer! I do have 4 x 16TB + 1 x 16TB parity, so I'm good then. I guess I got lucky it was the parity drive this time. What solutions are open to me, to protect my privacy if I have to send in array drives for warranty next time? Encryption (XFS encyrpted?) is the only solution, correct?

TL;DR: my parity drive has failed. Insurance/extended warranty wants to inspect the drive before they decide it can't be fixed and deserves a replacement/refund. Drive is too far gone to be wiped. Is data written to the parity drive by Unraid something readable which a data specialist could extract? I have critical personal files on there which I'm not comfortable sharing. My parity drive has failed recently, with increasing numbers of reallocated sectors and other SMART errors. I pulled it from Unraid as soon as it became clear it wasn't a one-off issue, but a cascading failure. I chose an extended warranty on that drive, due to it being a refurbished drive. The insurance company has accepted my claim. But they want the drive to "make sure it can't be fixed", before they decide to replace it or refund it. There's already a DHL pickup scheduled for tomorrow, before I could say anything. I'm wary of giving them the drive, since I have critical personal information on there: from copies of ID and banking statements to girlfriend's nudes, with everything you could possibly imagine in between. Basically all you need for identity theft and/or extortion. I obviously can't wipe the drive before the pickup, since it's failing hard. I've turned it back on a few times in Windows on a 3.5" to USB adapter to diagnose with CrystalDiskInfo and HDD Sentinel. But now it's not recognised in Windows anymore. Is the data written to the parity drive something which could be readable to a data recovery specialist? Which is who I assume the drive is going to once DHL picks it up for the insurance company. As the TL;DR said, there's tons of stuff on my array which is none of their business. I'd appreciate any information or help you may have on this. Thanks!

I'm honestly not so sure. Limetech themselves seem to care about it enough to have a blog about it on their homepage. And their latest article is about choosing the right hardware to keep power costs down. I'd wager a non-negligible amount of people who are tech savvy enough to pick up Unraid, are probably also going down the C-state rabbit hole. Since unlike the TrueNAS community, I don't think most of us here are running homelabs where power efficiency is sacrificed on the altar of a hobby. 😂 Unraid also strikes me as an OS designed around power efficiency, since the whole value add compared to TrueNAS is you don't have to spin up all the disks to read from any single drive. No problem. To refocus on the original question though: Is it possible to install a driver without a plugin on Unraid? Is the dedicated Realtek Linux driver I mentioned earlier (copied the README) something which could be packaged into this plugin, or installed manually? I've attached it here for everyone's convenience. r8127-11.015.00.tar.bz2 For context also, it's the highlighted file on Realtek's website.

Unfortunately, as I mentioned in a previous comment, the kernel driver is apparently bad and disables power saving. A system running an RTL8126 (5Gbe) or 8127 (10Gbe) will be unable to go below C3: I've read here and there that the dedicated driver from Realtek fixes this, which is why I've been inquiring about packaging the Realtek driver instead.

Would you mind answering a few questions, since you're daily driving this setup? How do you backup and restore before taking the plunge to a custom kernel? I've never done this outside atomic distros. Do you just use Unraid Connect's flash backup function? What happens to this custom kernel through restarts/updates? It gets replaced by the default kernel every update, correct? Is ASPM correctly enabled? (Can be checked with ASPM Helper plugin or lspci -vvv ) Even if ASPM is enabled, kernel Realtek drivers are known to limit CPU C-states. Would you mind confirming with Powertop that your setup can go below C3 at idle? (If your other components allow it of course) Thanks in advance!

Good idea for file integrity, I didn't think about that! I'm hoping this works, because my TEG-10GECSFP is the only 10Gbe SFP+ NIC (that isn't a 130€ Intel X710) which "supports" ASPM where I live. If I can't get it to work stable, I guess I'll just switch back to RJ45. I'm firmly in the camp of scrolling down in the log, rather than potentially missing something important ha ha Thanks for your help!

Thanks alturismo for your pointers. L0s L1 turned out to be unstable (judging by the logs). I suspect this is because the PCIe root, according to ASPM Helper and my BIOS settings, only supports L1. So not only does L1 lower power consumption by around 8W compared to L0s L1, it is also more stable. I do have another question: L1 has been stable so far in the sense that all my apps work, and (as far as I can see) I never lose connection. But in the logs I now see the same errors I saw with L0s L1, just much less frequent. Is it safe to leave L1 enabled in ASPM Helper, or is it a sign I should live with no ASPM on that device, or replace it with a NIC that natively supports ASPM? For context, I get this error every hour or two, instead of hundreds of times per second with L0s L1. Here is a text copy for your convenience. The root and device addresses match the device I force enabled L1 to. 05:00.0 is my TEG-10GECSFP 10Gbe SFP+ NIC. 00:1c.4 is the PCIe root it is connected to. NIC error: Dec 19 10:40:35 Tower kernel: pcieport 0000:00:1c.4: AER: Multiple Correctable error message received from 0000:05:00.0 Dec 19 10:40:35 Tower kernel: atlantic 0000:05:00.0: PCIe Bus Error: severity=Correctable, type=Physical Layer, (Receiver ID) Dec 19 10:40:35 Tower kernel: atlantic 0000:05:00.0: device [1d6a:00b1] error status/mask=000000c1/0000a000 Root error (which the NIC is connected to): Dec 19 10:40:35 Tower kernel: pcieport 0000:00:1c.4: AER: Correctable error message received from 0000:00:1c.4 Dec 19 10:40:35 Tower kernel: pcieport 0000:00:1c.4: PCIe Bus Error: severity=Correctable, type=Data Link Layer, (Transmitter ID) Dec 19 10:40:35 Tower kernel: pcieport 0000:00:1c.4: device [8086:7a3c] error status/mask=00001000/00002000Thanks again for your time.

Hello! If a device supports L0sL1 (which I have to manually force through ASPM Helper), is it better to: Force L1? In my testing this allows my system to reach 80% C6. Force L0sL1? In my testing this allows the system to reach 60% C3, 25% C6. L1 is clearly superior at complete idle. But when the server is experiencing light load (seeding torrents, Plex every once in a while, etc), I can't help but think forcing L1 will prevent standby that could have been achieved with L0s. L1 feels like "all or nothing", while L0sL1 feels like it keeps the door open for standby during lighter loads which wouldn't reach L1. Or maybe, if it can't reach L1 due to activity, it can't reach L0s either? I can't really simulate seeding/daily use in a repeated manner, hence why I ask here. Any thoughts? Thanks!

I've been checking the README of the RTL8127 driver package from Realtek's website. I've pasted it below. Having no experience with installing drivers outside of plugins in CA, I have a few questions: Is manually installing the driver like the README instructs possible under Unraid? If so, this install would be wiped at every update, correct? Is this "manual" driver any different than the kernel driver that's coming soon™ ? Can this package serve as the basis for a CA plugin? Moreover, I'd just like to join the voices calling for a plugin for this chipset. It is the 10Gbe NIC for the masses: it's dirt cheap (38€ on Aliexpress atm), supports both SFP+ and RJ45, comes in PCIe4.0 x1 slots, consumes less than 2W, and supports ASPM out of the box (even though it for now locks C-states at C3 - similar behaviour to other RTL kernel drivers that have power savings off due to instability). In comparison: Intel X710 supports ASPM and C7+; but cost an arm and a leg, have 2 ports minimum, and come only in x8 format. AQC113 comes in PCIe 4.0 x1 slots; but is 50-100% more expensive than the RTL8127, uses double the power, is RJ45 only, and needs to be flashed with custom firmware to even support ASPM and C7+. AQN100 is SFP+, supports ASPM and C7+, but the driver is apparently not included in the kernel anymore, and is now unstable according to Unraid forums. Then there's all the X520/X540/X550 which "support" ASPM, but lock C-states to C3. I've seen how long we had to wait for Unraid to update the Kernel. And I've seen how bad these kernel drivers can be (RTL8125 still have power saving disabled in the kernel due to instability on early models, fucking over other users). I'd literally be down to pool some money to get this plugin done by the community, but done right with ASPM and C-state support. Even if Unraid updates the kernel, the RTL8127 kernel driver is currently broken and does not go further than C3. But some commenters seem to claim using this driver from Realtek directly would allow for better power management. <Linux device driver for Realtek Ethernet controllers> This is the Linux device driver released for Realtek 5 Gigabit Ethernet controllers with PCI-Express interface. <Requirements> - Kernel source tree (supported Linux kernel 2.6.x and 2.4.x) - For linux kernel 2.4.x, this driver supports 2.4.20 and latter. - Compiler/binutils for kernel compilation <Quick install with proper kernel settings> Unpack the tarball : # tar vjxf r8127-11.aaa.bb.tar.bz2 Change to the directory: # cd r8127-11.aaa.bb If you are running the target kernel, then you should be able to do : # ./autorun.sh (as root or with sudo) You can check whether the driver is loaded by using following commands. # lsmod | grep r8127 # ifconfig -a If there is a device name, ethX, shown on the monitor, the linux driver is loaded. Then, you can use the following command to activate the ethX. # ifconfig ethX up ,where X=0,1,2,... <Set the network related information> 1. Set manually a. Set the IP address of your machine. # ifconfig ethX "the IP address of your machine" b. Set the IP address of DNS. Insert the following configuration in /etc/resolv.conf. nameserver "the IP address of DNS" c. Set the IP address of gateway. # route add default gw "the IP address of gateway" 2. Set by doing configurations in /etc/sysconfig/network-scripts /ifcfg-ethX for Redhat and Fedora, or /etc/sysconfig/network /ifcfg-ethX for SuSE. There are two examples to set network configurations. a. Fixed IP address: DEVICE=eth0 BOOTPROTO=static ONBOOT=yes TYPE=ethernet NETMASK=255.255.255.0 IPADDR=192.168.1.1 GATEWAY=192.168.1.254 BROADCAST=192.168.1.255 b. DHCP: DEVICE=eth0 BOOTPROTO=dhcp ONBOOT=yes <Modify the MAC address> There are two ways to modify the MAC address of the NIC. 1. Use ifconfig: # ifconfig ethX hw ether YY:YY:YY:YY:YY:YY ,where X is the device number assigned by Linux kernel, and YY:YY:YY:YY:YY:YY is the MAC address assigned by the user. 2. Use ip: # ip link set ethX address YY:YY:YY:YY:YY:YY ,where X is the device number assigned by Linux kernel, and YY:YY:YY:YY:YY:YY is the MAC address assigned by the user. <Force Link Status> 1. Force the link status when insert the driver. If the user is in the path ~/r8127, the link status can be forced to one of the 5 modes as following command. # insmod ./src/r8127.ko speed=SPEED_MODE duplex=DUPLEX_MODE autoneg=NWAY_OPTION ,where SPEED_MODE = 1000 for 1000Mbps = 100 for 100Mbps = 10 for 10Mbps DUPLEX_MODE = 0 for half-duplex = 1 for full-duplex NWAY_OPTION = 0 for auto-negotiation off (true force) = 1 for auto-negotiation on (nway force) For example: # insmod ./src/r8127.ko speed=100 duplex=0 autoneg=1 will force PHY to operate in 100Mpbs Half-duplex(nway force). 2. Force the link status by using ethtool. a. Insert the driver first. b. Make sure that ethtool exists in /sbin. c. Force the link status as the following command. 2.5G before kernel v4.10 # ethtool -s eth0 autoneg on advertise 0x802f 2.5G for kernel v4.10 and later # ethtool -s eth0 autoneg on advertise 0x80000000002f 5G for kernel v4.10 and later (Couldn't be supported before kernel v4.10) # ethtool -s eth0 autoneg on advertise 0x180000000002f # ethtool -s eth0 autoneg on advertise 0x1000 (10G) # ethtool -s eth0 autoneg on advertise 0x002f (1G) # ethtool -s eth0 autoneg on advertise 0x000f (100M full) # ethtool -s eth0 autoneg on advertise 0x0003 (10M full) <Jumbo Frame> Transmitting Jumbo Frames, whose packet size is bigger than 1500 bytes, please change mtu by the following command. # ifconfig ethX mtu MTU , where X=0,1,2,..., and MTU is configured by user. RTL8127 supports Jumbo Frame size up to 9 kBytes. <EEE> Get/Set device EEE status Get EEE device status # ethtool --show-eee enp1s0 Set EEE device status # ethtool --set-eee enp1s0 eee on tx-lpi on tx-timer 1546 advertise 0x0008 (100M full) # ethtool --set-eee enp1s0 eee on tx-lpi on tx-timer 1546 advertise 0x0020 (1G) # ethtool --set-eee enp1s0 eee on tx-lpi on tx-timer 1546 advertise 0x8000 (2.5G)

Yeah, I never planned to use ZFS on the array, since single disk parity and individual disk spinup was the whole reason I chose Unraid. If I ever need a ZFS HDD server, I'll either run it in pools or just use TrueNAS. I have a side question regarding that. I'm not quite sure I understood the Unraid documentation regarding exclusive shares. Does it mean: /mnt/user/data becomes identical to /mnt/pool/data and both can be used interchangeably? /mnt/pool/data becomes the default option? I ask, because when installing new dockers after enabling exclusive shares, the default paths seem to randomly alternate between /mnt/user/... and /mnt/pool/... That's good to hear from you over anyone else. Were there any significant ZFS changes between 7.0 (the version the user in that post is running) and 7.1.4? Because if not I still can't explain what causes the orders of magnitude slower speeds of ZFS compared to BTRFS in that post. One one hand, he's running 32GB of RAM, and I assume he had enough free for ARC. His screenshots indicate he's using direct paths to pools, skipping FUSE overhead. On the other he's not really running a clean test since he's comparing a BTRFS RAID1 of 2 different drives, with a single disk ZFS pool of yet another drive model. The obvious answer is to test for myself, but I just don't have the spare hardware or server downtime to test for myself. Quality resources on ZFS vs BTRFS in pools on Unraid specifically are pretty much nonexistent. The Unraid documentation does a good job explaining the different file systems, but is still very surface level with no performance comparisons; and advertising snapshot support when there's still no built in snapshot tools (afaik) in Unraid is a bit disingenuous. The Snapshot plugin for BTRFS hasn't been updated in 2 years either, which only leaves btrbk and good old elbow grease. Do you have any opinion or experience you'd like to share on ZFS vs BTRFS for Unraid pools? BTRFS has worked fine so far, but the snapshot experience is not great. I'm about to get into some database-heavy stuff with critical data, so I'd like to commit to a file system before I start setting all that up.

I've stumbled upon this post detailing a user's experience and testing with ZFS (both array and pools) on Unraid. Anecdotally, I also often read about disappointing and unusually slow ZFS performance on Unraid, as compared to BTRFS. Even with NVMe pools where performance should be no issue whatsoever. I understand ZFS on the Unraid array is a special (and discouraged) use case, but pools should not be affected afaik. Personally, I've always stuck with BTRFS, but I am getting tired of the lack of proper GUI/native systems in Unraid to manage snapshots. So I've been itching to give ZFS a try, to see if the snapshot experience was any better; but these experiences have been putting me off. Reading into them however, no one seems to give a concrete explanation as to why ZFS pool performance is so poor in Unraid. Could someone more technically minded than me comment on this, and hopefully give an explanation?

Alright, I'll keep an eye on this in the coming updates. Thanks for your help!

Glad to hear LT is working on it. For now it isn't the end of the world, since I've been able to pin TOWER to the quick access bar with the array stopped. So therefore the issue is unrelated to my using New Permissions and Appdata Backup? I very recently updated from 6.12.x to 7.1.4, which would explain why I hadn't had the issue until now. It is very likely that I simply didn't notice the workgroup issue in the new update, until my mistake with New Permissions brought my attention to it.

It does indeed! How come?

Some important context - I nuked my appdata share permissions with the New Permissions tool, because I'm an idiot who can't read the warning. Thankfully I had the Appdata Backup plugin, and I deleted the nuked appdata share and repopulated a new one of the same name, to avoid having to chmod 777 the existing share. All is well and good on that front, and I have been able to restore my docker containers without issue. However I now encounter the issue I described in the title. I do not know if this is caused by my New Permissions fuckup, or something else in my troubleshooting/restore steps. But it coincides perfectly with this disaster, so I assume it is related. To elaborate, my Unraid server used to show up as a connectable computer called "Tower" in my Windows workgroup (as does my desktop called "North_Breton" in the linked screenshot). This was handy since it meant I did not have to mount every share as a network drive/network location, hence cluttering my file explorer. It no longer appears in that workgroup area (the "Network" section of the Windows file explorer). However I noticed that for a few seconds after boot, the Unraid "Tower" is briefly visible and accessible, but disappears soon after. I also noticed that while the "Tower" disappears, the server and its SMB shares are still accessible when typing the adress manually in adress bar ( "\\TOWER" or "\\TOWER\appdata\plex" for instance ). Any ideas on what may cause this, and how to resolve this? Thanks in advance. Edit: forgot attachment.

As the title says. Here's my setup: I have an array with a bunch of HDDs for Plex. I have 2 x 1TB old NVMe SSDs in RAID 1 btrfs from when I started my NAS, and Appdata lives there. I have 2 x 4TB modern NVMe SSDs in RAID 1 btrfs which I bought to make a dedicated high-availability share for files I use often (nextcloud, immich, etc ). I got frustrated with HDD speeds and latency for daily use files, when I have 10G networking in my home. But then it hit me that I may as well just migrate Appdata onto the modern, high endurance 4TB drives. Pros: Frees up PCIe lanes from 2 NVMes instead of 4. Lowers power consumption for the same reason. Migrates Appdata to new drives with fresh, and longer lasting endurance. The new drives don't thermal throttle, unlike the piece of shit that was the Crucial P1. Cons: Less neat, due to not having dedicated pools for each use (not really an issue?) Depending on use cases, Appdata endurance becomes vulnerable to write wear caused by the high-availability share. But these drives have much more endurance, and aren't at the end of their life like the current Appdata SSDs. Plus I run the appdata backup plugin daily due to game servers living there. Am I missing anything? It feels like there's no downside to consolidating, but it feels wrong to me. Hence why I'm fishing for ideas/experience. Thoughts?

Hello! I've been happily using the binhex-minecraftserver for years at this point, without issues. Today I noticed that the WebUI is an empty black screen, with only a single text marker at the bottom left. I mainly use Firefox, but switching to Brave resolved the issue. This is strange because I have used this WebUI on Firefox without issue for years, and as far as I can tell nothing has changed - I haven't had a Firefox update in a while. Disabling uBlock Origin, Firefox native security settings, clearing cache, and opening the WebUI in a private tab do not resolve the issue. Any thoughts? Thanks!

Something's definitely wrong then. DFM speeds have dropped to 9MB/s max this morning, and the time elapsed vs amount of data transferred math backs that up. It's now saying it needs 4 more days for the remaining 4TB. So almost a week in all to move 9TB from one share to another... And that's assuming it doesn't slow down more over time than it already did. Since you seem more familiar than I am with DFM, the way it moves data is Copy and Delete right? So if I cancel the move, what's already been transferred will be in the new share, while the leftovers remain in the old share. Correct? What happens to the file currently being copied? Since DFM is Copy and Delete, the original version of the current file should be intact and not deleted until it has been completed, correct? I've also looked into rsync and MC, and it looks like the big speed improvement is because they first attempt a File Rename rather than Copy and Delete like DFM. Since all my user shares have no excluded disks and are spread out across my entire array, and I don't use disk shares, I should be fine with these limitations, correct? It doesn't matter that it doesn't actually move the file, just rename the path, since all shares are already spread to all disks. Sorry for coming back with more questions, but I'm kind of starting to pull my hair out with how much it's slowing down, for no obvious reason. Thanks in advance.

I was referring to the speeds here: Which consistently, throughout the entire run, do not match the speeds I'm seeing here: How can the drives be writing faster than the speed at which the transfer takes place, throughout the entire run? And the math with the elapsed time seems to show the DFM estimate is accurate. In theory I'd agree, but these writes are about as sequential as it gets in real world usage, with large, 30-50GB files. I was surprised to see these large files write slower than when I back up hundreds of 20-30MB photos directly to the array, where I see around 100MB/s consistently. The only difference is this is a move operation, not a write from outside the array. So as JorgeB mentioned, turbo writes don't work within the array itself, and there's an extra initial read operation I assume. So the slowdown has to be some combination of "read/modify/write's" innate slowness, the overhead/extra reads from a move operation rather than writing from an outside source, FUSE overhead from writing one share to another, and/or some funkiness with how DFM works. Which is why I really need to take the time to test variables to see what, specifically, causes the slowdown.

Thank you, I'll look into those for the next batch I need to transfer. Guess this might be another reason to upgrade to Unraid 7 then (array-less pools). ----- On a side note, I stumbled on another post about painfully slow DFM transfers, which you answered back in 2022. It made me do some quick math regarding my own transfer: if the average parity disk write speed I'm seeing in the "Main" tab on the Unraid GUI was accurate (~150MB/s), this whole thing would have been done in around 19 hours. The move has been running for almost exactly 24 hours at this point, and I'm only barely halfway through the 9TB. So the writes I'm seeing on the parity drive can't possibly be accurate, or they're not all contributing to the move order. (I currently have no other process working on the array). So it seems that the speeds reported by DFM are indeed accurate. One thing I noticed looking more attentively, is the DFM speed sometimes spikes to around 60MB/s, which you mentioned was the realistic maximum for an intra-array move; yet it also comes crashing down as low as 5MB/s regulary. When you mentioned this 40-60MB/s maximum, was it sustained or peak speeds? What could explain such speed volatility? Errors in DFM reporting; inefficiencies inherent to the parity process, fragmentation issues (is defragging even a thing in Unraid)? Either way, at least I'm seeing peaks which match your stated real-world maximum. The initial 100MB/s I was seeing must have been attributed to the large cache on these enterprise drives. ---- I'll run some tests another time: with the other tools you mentioned, without FUSE overhead, and within a pool of two drives to try and single out variables. I'll mark this post as solved for now, as the 40-60MB/s you mentioned give me the context I need to understand the numbers I'm seeing on my end are not completely out of the ordinary. Thanks for taking the time to answer!

Good to know, thank you. Is this something that still affects the new "integrated" DFM in Unraid 7? By other apps, do you mean Krusader? Final question: if I write a lot to my array, and have so few drives that having them spun up all the time isn't a dealbreaker, would this be a use case where I could benefit from the new ZFS filesystem?

So to hearken back to my initial questions: The numbers I'm seeing are expected behaviour? 4 days to move 9TB from one share to another? Using the "move" button in the Unraid GUI is still the most efficient way to transfer files from one share to another?

I have read that page, which is where I discovered and then decided to enable turbo writes to begin with. However, it doesn't feature any examples or numbers (which I can understand, for several reasons). So I understand the fundamental process, the pros and cons of each approach, yet I still have exactly zero context to understand whether my numbers are expected, or on the contrary, worrying. Correct me if I'm wrong, but a parity sync also involves a seek and write operation, yet my drives fly through those at around 200MB/s, slowing over time to 170-180MB/s. 20MB/s is an order of magnitude of a difference compared to a theoretical maximum of 270MB/s, and a real-world maximum of 200MB/s during parity checks. That can't be right can it?

Hello, I'm running a server with 3 x 16TB 7200rpm drives, with one being parity. I get around 270MB/s R/W when benchmarking these drives. I'm running an i3-10100, so I'm in no way CPU limited. I also have 32GB of RAM. I am trying to move all the contents of an old share to a new one. I have used the built-in GUI "move" button, as Unbalanced does not allow for (as far as I know) moving files from one share to another. Since these files combined weigh around 9TB of large Blu Ray remuxes, I have enabled turbo writes to speed up the process, by setting "md_write_method" to "reconstruct write". Since my setup only has 2 drives (excluding parity), the files are individually extremely large (30-50GB each) and data is already present on both drives (through FUSE), there shouldn't be too much IO overhead, and should be pretty much a best case scenario for sequential R/W. There are essentially 2 problems: Initially the transfer speed started out as around 100MB/s - itself nowhere near the 270MB/s the drives should be able to reach on large, sequential files like these. During parity operations, and writing to the array itself, write speeds top out at 80MB/s with read/modify/write, and around 100MB/s with reconstruct write. Moreover, it estimated around 6 hours to finish the job, yet I wake up this morning with the move only 30% completed, and with transfer speeds crashing down to 20-30MB/s. This would take around 2 to 3 more days according to the GUI estimate. Here are my questions: What gives? Why are my 270MB/s drives limited to 100MB/s, when all drives are identical, turbo writes are enabled, and the files themselves are a best case scenario of single, huge files, as close as it can get to sequential R/W tests? What caused the catastrophic drop in transfer speed from 100MB/s to 20-30MB/s? What is the preferred way to move a large amount of data from one share to another? I assumed it would be the built-in GUI "move" button. Does Unbalanced allow from transfers from one share to another? Should I have preferred copying through Windows from one SMB share to another? Why do transfer speeds in the move GUI not match disk R/W speeds in the "Main" tab? Does RAM usage affect transfer speeds? I have 32GB of RAM, and killing a game hosting process which brought total use from 91% to 15%, has caused transfer speed to be much more erratic: highs now reach 70-80MB/s, lows now go down to 10MB/s. It's much more erratic now. I'm not quite sure what info to include here, but I'll answer as soon as I can with any requested info. Thanks in advance.

Hello everyone, I'm currently running 4 x 4TB Ironwolf drives + 1 in parity + 1 Blu Ray reader. This maxes out the 6 SATA ports I have on my Z490 motherboard hosting an i3 10100. I want to increase the number of ports available to me, ideally without an HBA (airflow and mental health concerns, see TL;DR). I plan on buying more, larger hard drives at the same time. My server mainly runs a Plex/Jellyfin server of 4K Remuxes, which Direct Play 95% of the time (so an iGPU is not an *absolute* must have). It also hosts a few game servers, with ~4 clients max each. Finally it runs qBittorrent with a several TB permaseed share. I do plan to add Homeassistant and maybe Nextcloud in the future. Here are the options I can think of, and I'd like your opinion on them: I have an Adaptec 71605 HBA in HBA mode I found on a bargain. It could handle 16 SATA ports, but I absolutely hate it: it burns up insanely quickly, needs a ton of airflow, and forces me to boot in CSM rather than UEFI. Apparently 10th gen Intel has issues with CSM or *something*, and I can't access the BIOS with the iGPU anymore when I turn CSM on. It needs a dedicated GPU - which I do not have. I had to spend hours pulling out my 7900XT which now barely fits in the server, just to troubleshoot. The HBA will work just fine in Unraid, I just lose access to BIOS in the process. I honestly can't be bothered (with a 10th gen Intel CPU, but I have no guarantee it'll work any better with other platforms). This is my least favorite option: it requires a ton of fixing issues (overheating, no BIOS in CSM, configuring write cache as it has issues with that, etc). I have a generic Asmedia 1064 SATA expander. 4 x SATA in a Gen 3 x1 slot. Has honestly been rock solid performance wise despite what people say about them - I think it supports deep sleep and ASPM; *BUT* it suffers from the powertop autotune glitch: running powertop autotune will cause drives to lose connection to the SATA expander once it enters deep sleep. Had to parity check the whole array once because of this. Does not affect my Blu Ray drive though, but that's only one of the 4 SATA ports it offers. Do I really need the powertop autotune command if it already supports PCIe Deep Sleep (L0/L1/etc) and ASPM? If not, this could be a cheap, simple option. I could upgrade to LGA1700. I've spotted a cheap motherboard with 8 x SATA and 3 x NVMe, not shared with anything else PCIe/IO wise. Perfect. I can grab a 12th/13th gen i3, or even an i5 if I want more cores and the UHD770 with double Quicksync. But upgrading for 2 extra SATA ports and an extra Quicksync engine feels stupid. I could switch to AM4. My workstation currently runs a Ryzen 9 5950X, and I could reuse it in the server to give myself an excuse to upgrade my main rig. On one hand, I'd have *MUCH* more power to expand my activities for years (the i3 10100 already has hiccups when software transcoding (thanks, Plex; take notes from Jellyfin's hardware transcoding) + seeding + game hosting), and there are plenty of cheap X570 boards with 8 x SATA and 2 x NVMe. On the other hand, I'd have to run headless and give up Quicksync: not the end of the world since I almost always direct play, but I won't have access to BIOS unless I buy a cheap GT710 or something for troubleshooting. A combination of several solutions: since the no video out/no boot issue with CSM seems to be an Intel 10th gen issue; maybe switching to LGA 1700 or AM4 will allow me to use my Adaptec HBA without issues? TL;DR: need more SATA for my Unraid build, up to 11 max. Very interested in keeping power consumption down through either efficient chipset SATA, or proper ASPM/Deep Sleep PCIe expanders/HBAs. Want to keep things simple for my mental health's sake (spent days troubleshooting the Adaptec 71605 HBA and it has honestly ruined with week).