Lev

Tested inside a VM running within UnRAID. Everything looks as expected, nothing exciting to report. That's a good thing 😄

@bonienlvery nice improvements and fixes. I always much appreciate this minor releases where the Ux gets a bit more polish 🥰 Flawless upgrade from 6.8.2. Everything in the logs and system behavior is as expected.

Almost 3 years later.... I've returned to this thread looking for answers to go beyond the drive count limits. I have a lot of drives. Maybe 60 or so. Presently I run UnRAID on bare metal, with two nested VMs that also run UnRaid. Tota of three UnRAID pro licenses to make this possible, each with their own USB key pass-thru to the VM. It's awesome and it works @limetech. The bare metal is 36 bay SuperMicro server with external SAS cards that attach to a SuperMicro JBOD array. I want to add more drives. A lot more drives. I recently came into possession of 4 of those BackBlaze 45 drive storinators. The backplanes and SATA expanders can be mapped to two UnRAID instances. It'd be split with 30 disks to one UnRaid instance, and 15 to the other UnRAID. That 15 seem inefficent and is nagging at me to find something else to have a single 45 drive array. What's the answer? I've been researching SnapRaid. Seems viable. If I explore deeper I'll start a threat on my findings and link back to this thread. This thread is important. Years gone by and looking at where I am now, versus where I was when I posted here. The drive limit hasn't changed. UnRAID is still awesome. But my needs have changed. I'm happy to purchase more UnRAID licenses, but I don't want to manage multiple UnRaid servers. Three is enough. Any ideas on what else to explore or consider?

Three days of solid stability. Everything looks as expected. Nice work.

@limetech Tom are there any specific test cases that could be performed that would help provide you more information?

@johnnie.black I'd like to gather some data to assist. To align with your tests, could I get a copy of your spreadsheet so I can plug in my numbers?

Any updates on the known issue regarding slower parity sync/check for large arrays?

I was also going to recommend this @IamSpartacus. I've experienced something similar when I was booting ESXi and switching EFI / Legacy boot resolved it.

I've got a backup mirror of my Steam game library that seems to be an ideal use case for compression. Curious did anyone try @johnnie.black's suggestion? If so how's it working for you? What's the performance impact?

I checked mine, I can't reproduce this.

Wow I've been using this and it's simply amazing. Huge thank you to integrating this into Unraid.

🤦‍♂️Would you believe before I posted I was so worried about embarrassing myself that I read every post, except the first post... 🤣 FML

Good to know, thanks Johnnie. I had a feeling you would of already spotted the issue since we both run large arrays.

Here's diagnostics from rc3, do you also want to see 6.7.2 ?

I've consistently reproduced parity check speeds that are roughly 30MB/s slower with 6.8.0-rc1 & rc3 (both the same 143MB/s) vs. 6.7.2 (173MB/s) So far I've tested all three builds mentioned, and within rc3 I've tried mq-deadline & kyber but didn't see any difference. What else should I be looking at?