dev_guy

Delete it how? I don't see any obvious things to delete in my array? And why was a folder created in my array in the first place when this share was created to ONLY USE CACHE from the very start? This seriously seems like a problem that needs to be addressed? It's easily re-created. This isn't some fringe weird issue. It's something anyone can recreate in a few easy steps. Unraid seems to be broken if it's writing things to the array for newly created shares that are supposed to only use cache. Can you explain how I have this wrong?

Clicking on compute shows SIX BYTES on the array. Again, there seems to be no reason for this? Why did Unraid write 6 bytes of information to the array for a newly created share that's set to "Yes" or cache only? How can someone prevent Unraid from doing what it's not supposed to do?

The shares flagged as "unprotected" have no data on the array. They were created recently and have always been set to "Yes" for cache only hence have never had data on the array unless there's some bug in Unraid that writes data to the array even when you create a share that's supposed to always use a cache pool? This really seems like a bug?

The main array currently has a missing disk. But, if you'll note, the shares are set to "Yes" meaning they shouldn't care about the Unraid array as data will never be stored there. And the "System" share is happy with the situation despite being set to "Yes" on the same cache. This very much seems like a bug in the latest version of Unraid?

I'm having this issue as well and it shows unprotected on the Shares tab with the warning triangles. I have two mirrored "Raid 1" btrfs cache pools set up (one with a pair of SSDs and one with a pair of conventional drives) and Unraid considers some of the shares using them to be unprotected. The "System" share using the same cache is happy. Why? Please see the attached screen shots.

@JorgeB thanks for the answer and suggestions! I wasn't aware SMB is significantly better in 6.11. The disk share idea is also interesting. I believe the file I/O in Unraid shares is perhaps going through Fuse? If so, that would help explain the abysmal performance reading large numbers of small files. I know NFS offers much better performance with small files as well. So perhaps NFS plus a disk share might approach the speed of the drive itself.

But my Unraid machines also handle multiple VMs and dockers and they idle at 15 watts and 23 watts. Your server is using around 10 times more power doing nothing. It's not the fault of Unraid it's using the wrong hardware. It's like buying a V12 Lamborghini and complaining it uses way more fuel than a Toyota Prius.

Why does it often take 3 separate steps, having to apply each along the way to reveal the next step, to apply share permissions? With any other NAS OS I know of you can do it all in one step and only click "apply" once. Why not just put all the options initially on the same screen instead of slowly revealing them like some kind of shell game?

Two unraid licenses but only one server runs 7x24 currently. I have other servers running 7x24 including OpenMediaVault and commercial NAS units. There are just too many performance and other issues with Unraid for it to be my sole solution.

Well it's still part of the issue. I have a gaming rig with an RTX3060. It idles at around 60 watts and about 15% of that is the graphics card. But you're basically trying to use a gaming rig as a 24x7 Unraid server. That's just not going to be efficient no matter what you do.

In my experience AMD desktop/gaming/server CPUs are much worse than Intel for real world power consumption especially at idle. Adding two power hungry graphics cards just makes your problem worse. I don't think there's an easy fix besides moving to more power efficient hardware. Depending on electricity rates in your area you could spend more on power in a year or two than it would cost to switch to much more power efficient hardware. I have two Unraid systems. One idles at 15 watts with the drives sleeping and the other idles at 23 watts with the drives sleeping. That's power consumption as measured from the wall with a Kill-A-Watt meter. Both are recent generation Intel with no graphics cards. Neither of them has been CPU limited even with many dockers and a few VMs running. So, depending on your use cases 300 watts, is just a huge waste of energy. If you want to game then use a gaming rig that's only powered up when you're actually gaming. That's much more power efficient than using a power hungry gaming grade rig powered 7x24 for an Unraid server.

Thanks for your work on this and posting the PDF.

This is a bit odd but I wanted to see if I'm going to break anything (namely parity) if I try this? Can I shutdown my server, remove a XFS data drive from the array, mount it read only on a Linux system to work with the data on the drive, and then return it to the array? If it's mounted as read only while out of the array will everything be okay? Or am I missing something? The reason for doing this is strictly performance. It's 12TB of data, with half a million files, and accessing it over the LAN via Unraid is proving to be painfully slow and easily an order of magnitude slower than having it be a local SATA drive. For whatever reason Unraid is rather slow for a large number of small reads over the LAN. So will my array never miss the drive being borrowed for a while as read only? Or will some bit get flipped somewhere throwing off the block parity calculations?

Thanks! I'll give that a try although it's happening on multiple PCs/laptops. It's possible none of them have been re-booted, had cookies cleared, etc. Just as feedback for the Unraid team, that's a poor way to handle things. If a user selects "never check" for updates you shouldn't nag them under any circumstances. Or, worst case, only nag them once and never again after they dismiss the first update notice. It's something Unraid should fix especially given it's a paid product.

I have "Unraid OS Update Notification" set to "Never Check" yet I still get frequent annoying banners, pretty much every time I log on, telling me 6.11.1 is available. I'm running 6.10.3 and have no desire to update given the issues many users have reported with 6.11. Is there a way to stop these annoying upgrade banners? Why does Unraid not honor the "Never Check" option for those of us wanting to stay on our current version? This is more what I'd expect from Microsoft or Google trying to force updates not Unraid. I've searched the forums and have not found a solution. Any help would be appreciated if I'm missing a setting somewhere?

Thanks trurl. I love how responsive people are on this forum.

Thanks, but yeah, I'm starting with new disks and a completely different configuration. I've already moved most of my data to a NAS. I still don't know what happens if I use the USB Creator to install a new version onto the flash drive? Will it automatically license based on the serial number of the drive on a new system? Do I need to copy back the old .key file?

I'm wanting to do something similar. I want to retain my license and use the USB flash drive on entirely new hardware. It sounds like I can just delete everything except the .key file and pop the USB drive into the new server if I want to use the same version? What happens if I use the Unraid USB Creator on a licensed flash drive (which I assume will destroy the .key file) to start off with a newer version? Thanks!

Thanks for the reply and added info. That's what I suspected but I wasn't sure. It's great to get such prompt helpful answers here. Thanks again.

I have some assigned disks that are not yet part of any shares. I note despite never being part of a share they still indicate about 70GB used. Is there a way to remove one of these disks without rebuilding parity for the entire array? I'd like to go from 8 to 7 disks by removing an unused disk that's never been assigned to any shares and use that disk elsewhere without replacing it. Any advice would be great?

Interesting. Thanks for sharing that.

I agree for write once and read many times write performance is less important. But it's still frustrating having large copy operations taking days that would take hours even on a cheap RAID 5 NAS with the same drives. I understand the trade offs but they don't seem to be widely understood or sufficiently transparent. If Unraid was a free open source operating system I'd be less critical. But it's a proprietary paid OS I've paid hundreds of dollars for with both my servers and I'm disappointed.

@JorgeB, thanks for the added info. Some of this is a bit counter-intuitive but I do now better understand how Unraid works, some of the trade offs, and appreciate your help. The drives in this server are a mix of 7200 and 5400 RPM drives. None of them are SMR drives. I would think the parity drive, and the drive currently being used to store the files being written, would dictate the speed not the other drives in the array which have next to nothing being written to them? I've booted this server into Linux and run benchmarks on all the drives. They're all much faster than I'm seeing with Unraid even with turbo write but that's testing them individually. The disks are on an LSI/Avago SAS 9211-8i with IT mode firmware controller which is widely used for Unraid, FreeNAS, and other storage builds, with few complaints about performance. It's in a PCIe 3.0 x16 slot with a fast chipset. So there are no obvious bottlenecks with the hardware. @Constructor I do understand the difference between striped RAID and Unraid. With RAID 5 at least there's a bigger benefit to read performance than write performance. I provided a link supporting that. But even if we consider single drive performance I'm not seeing anywhere near that with Unraid. Ideally the bottle neck would be the USB 3 external drive but the bottle neck is clearly the Unraid OS itself. I can boot the exact same hardware into Linux and copy from a USB 3 external drive to an internal drive far faster than Unraid can manage. I understand Unraid is having to write to both the parity drive and the drive being used but the difference is relatively huge. At this point I'm willing to accept it's all about trade offs and if 40-45 MB/sec and 80-90 MB/sec "turbo" is all Unraid can manage on hardware that's capable of far higher speeds that's the answer to my question even if it's disappointing. Regardless, I appreciate the help and education from all who replied.

Preclearing is not the same as writing data. No parity is written for preclearing.

Thanks for the link but I still don't understand why ALL the drives have to be spun up for writes to a share that only uses a few drives? The other drives seem to be needlessly spun up as they're not part of the share and show no writes with their reported used space remaining the same even after copying a large amount of data to the share? I understand that "turbo write" is working as documented, but that doesn't mean it makes any sense? Yes RAID 5 has some READ performance advantages but it's generally considered to be at a disadvantage during writes. So it doesn't have some unfair striped advantage over Unraid. See: http://rickardnobel.se/raid-5-write-penalty/ You might be correct that most modern CPUs can handle the parity calculations without it being a limiting factor. But, to put this really simply, I can take the exact same drives, motherboard, and disk controller, running a different OS using software RAID 5, and get far better performance. So it's NOT the drives, controller, etc, that are constraining the performance. It's Unraid. Even with "turbo write" Unraid still takes 30+% longer to perform writes. What I'm getting out of all of this is I need to just accept Unraid has really poor write performance and, short of using cache as a band aid, there's nothing that can be done?