Lev

Rather than create a new thread, I thought I'd post here. I'm looking for the same command. I want to format a disk that I have in a different server running Debian and ensure it's formatted to be recogniziable by UnRAID. What is the command?

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?

If anyone has the following error using tmux, here's the workaround. Not sure when this was introduced, I'm presently running 6.8.0-rc3 Error message Run this command as a workaround

Upgraded two servers from 6.7.2, checked the logs, no issues to report. One server was bare metal, the other is a VM. The VM booted fine, everything passed thru as expected.

@SpencerJ question: Looking back from where Limetech began in 2005, what's been the most rewarding part of the journey over the years for Tom personally?

We all are brother. I love my USG but how much I wish for something better beyond there current offerings. That said, it's still the best for my use case compared to the competition.

I have used untangle for the last few days. Some thoughts... - Lots of charts and reports. Even a daily email with reports. Most if not all these reports the Unifi USG will also give, pfSense does not, or at least not without some work to setup initially. - Emails from the untangle sales team chat-bot. Even though I marked myself as a 'home' user, the automated bots are hot to sell me a license. - Very easy to setup and get running. Very easy user interface. I think this is it's main advantage over pfSense. After two days I completed what I wanted to find out about untangle and turned it off the server it was installed on. I'm happy I did it, I now know more than I did before and what works best for my use cases. I think my recommendation for @gacpac is to get started with Unifi USG as it'll cover 99% most use cases and it's integration with other Unifi products makes it so easy to manage a home or business network.

Thanks for this. Good things cost money, just like Unraid. I'm going to give untangle a try.

Between those two, definitely USG. I don't believe the ASUS RT-AC66 gets merlin builds anymore either. It's rather old. Yes brother, you're not alone in feeling that way.

@hawihoney some positive news to report. I did a PCIe pass through using one of the four physical network adapters in my server. Then on my host mounted the smb share of the VM guest Unraid using it's IP address assigned to this pass through adapter. It works! My Unraid VM has two network adapters now. The br0 virtual adapter and this second pass through adapter. Also more good news... I'm seeing transfer speeds at my disks maximum, >160MB/sec which is more than my one network adapter. I suspect this is smb multichannel at work spreading the file transfer across both network adapters. I'm very happy this works, now I can really scale out my 50+ hard drives across multiple Unraid VMs in a single server.

We're both running into the same wall. Glad I knew I wasn't the first, otherwise I would of kept running into thinking I wasn't doing something right. I appreciate your detailed posts in this thread. Same, seems from all our testing it's the only method that works reliably and has expected performance. That's one approach, I have another suggestion. Might be more reliable to use a common linux command (iostat) to query disk activity on the parity or plex disk to see if it's under heavy load. It has a few advantages to using the hidden file check method... more common tools agnostic to the application, and you can define a granular definition of 'heavy load' is to each applications use case.