SSD

On the Plex server configuration, you can select whether to enable or disable remote access. Is that not sufficient?

1 - After the initial install, no reason to reduce the core count for normal updates. If you ever have to boot from the .ISO image again, it might be needed. 2 - this is personal preference to a degree, but the best practice is to keep the vdisk lean and store your data on the array, or in an unassigned device. The vdisk contains the OS and installed programs only. The vdisk is easier to back up and all your data is externalitied, with the important parts parity protected. 3 - Not a Mac guy, but I'd experiment with options to externalize. You can create a second vdisk if desired. For my Windows VM, I wanted to keep my TEMP folder off the SSD, so created a vdisk on an unassigned spinner. (Windows was not happy with TEMP folder on a network drive, even if mapped to a drive letter.) But if you want the iTunes library on your OS vdisk, you can certainly do that. I just like to be able to compress and backup my image file, and having a 1T image would be completely impractical for me. Here is my setup: C: - vdisk mounted on SSD cache (backed up periodically) D: - vdisk mounted on unassigned device (temp folder) E: - mapped to spinner unassigned device F: - mapped to unassigned SSD - used for VMware VMs I run under Windows. I don't map array disks to drive letters, but can easily write to the array when needed.

I am doing parity checks every 2-3 months. Always do one before and after any disk / hardware activity. Between parity checks, I do md5 verification runs, which serve a similar purpose to parity check, but they check for file corruption instead of parity corruption.

@gridrunner may have other ideas. Reduction in gaming performance from >60 to 26 FPS is not typical.

I am not a gamer, but this is not typical of VM slowdowns I have read about. I'd expect reductions of maybe 20% or so. So there might still be something not quite right in your config. If this is the sole video card, you might try the ROM file in the XML. Could also be that you are not giving enough cores or memory. Or not allocating matching cores and matching hyper-thread cores properly. Review carefully and experiment and you might find something that could pump up the video performance.

Are you using unRAID?

Have you tried the Plex DVR feature? It will record and watching live TV via an HDHR.

Does sound like a bug of some kind. @bonienl might be interested. User shares are odd beasts. They are automatically created based on root level folders on your physical disks. So if, from the command line or via an SMB disk share, you created a root directory called FRED, you'd notice suddenly you have a user share called FRED. If you remove the FRED directory, the user share will disappear. Plot thickens a bit if, through the user shares WebGUI, you customise the user share. This will create a config file. With that config file present, I believe unRaid will continue to report the user share, even if the root level folders are gone. I would check your disks for the root level folder on your disks, and if you find, see if you can manually delete them. Could be a file or directory is still present inside. I expect that is the cause of the user share popping up after the reboot.

I know that general recommendation is, when a drive is being replaced, to remove it and let unRAID rebuild it onto a new disk. I seldom/never do that. I am normally replacing at least 2, and sometimes 3 or 4 at a time. And I will install them outside the array (making sure unRAID partitioning and formatting is applied), and COPY the files from the array disks to the replacement disks. This results in completely defragmented disks, rather than a clones of the existing fragmented disks. After all the copying is done (which can be done in parallel since there is not parity involved), I do a new config, and rebuild parity. Overall I find this a more efficient process, with defragging just being a nice side effect. Of course all of this is done only after a parity check and inspection of the SMART reports / notification emails to ensure that the drives are healthy. If done properly, it introduces no additional risk with minimal drawbacks, and a huge advantage in getting through the upgrade cycle quicker. One of the big benefits of defragmentation is enhanced ability to recover data in the event of some sort of disk corruption event. Unfortunately, XFS is a file system that is particularly poor at being able to recover from such events, defragged or not. So I would question the need to run the defrag tool. Beating the crap out of the drive for 48 hours may not be worth it! With media, the data is typically read back at a slow rate compared to the disk speed, and it will be able to easily keep up with your streaming even with some head movement. Also, when moving to XFS I did some digging into how XFS works,. We tend to think of a drive having a file allocation table that maintains the file linkages. But my understanding of XFS is that it is broken up, internally, into multiple blocks each having its own file allocation table. This tends to keep files within a band of cylinders, and minimize the bad side effects of the heads moving wildly back and forth over the disk surface to read a badly fragmented file. All in all, I would not be overly concerned with disk fragmentation in an XFS array. And if you are worried about it, next time you want to upsize some disks, use my method. Feel free to ask and I can give more details.

Just curious. How much energy savings would this provide for a typical user?

Installing an unRaid update requires a reboot, which would tend to limit the uptime, particularly recently. In the old days, we could have much longer periods between updates and have longer uptimes. An extremely long uptime means you are missing a lot of updates wish is probably not a good thing!

I believe so, but as I recall it depends on setting up properly with the NZBtoMedia tools to communicate between it and the DLer.

I have EVGA 1050Ti SC card. I found a vbios on techpowerup but it said it was untested, and it didn't work (bottom half of screen looked fine, but upper half was all screwed up. So I pulled my own using GPUZ. I installed the card in my old Windows box, ran GPUZ, and extracted the VBIOS. Then editted it with HxD to remove the "nvidia header". Put it on my server, added reference in my VM XML, and it works perfect.

It doesn't happen that often that a REAL read error will happen on rebuild. But it is INCREDIBLY common that a user exchanges a bad or upsizes an existing drive and they knock a cable askew and the result is an apparent failure. Dual parity lets the rebuild complete even if that second drive gets knocked offline. Then you can fix the second issue after the rebuild. With single parity the recovery is still very possible, but certainly more complex. Good cabling and drive cages will stop this phenomenon much more effectively, but dual parity is better than nothing. But I sometimes suggest NOT doing dual parity and instead doing drive cages. They seem unrelated. But this is the connection. And the price is similar. You don't get 100% protection from anything. But drives themselves are pretty darn reliable - certainly if you look at a failure window of 1-2 days, and assuming monthly parity checks, the chances of another drive failing while trying to recover from the first is awfully small. A single "rough spot" on a different disk can subtly corrupt the recovery, but with the file integrity information you can figure out what file(s) were impacted, and restore from backujp or another source. And if a drive fails and the recovery fails, you always have the failed disk. Having a disk fail so badly that you can't get data off of it is quite rare. You might have a bad spot that affects 1 or a small set of files, but typically the lion's share can be salvaged. The problem is that dual parity does not address the main reasons single parity recoveries don't work - and that is failing disks corrupting parity. You'd need something more akin to PAR blocks for such a recovery. I experimented with this a while back, but took forever to build and no way to keep updated without re-doing. This same phenomenon can happen with Freenas. So while not perfect, single parity is pretty darn effective. You have multiple angles to pursue recovery in the proper order. People tend to loose data when they don't know what do to and make mistakes in the process. But even then, the forum experts have a remarkably high success percentage of getting all or most of the data back. Dual parity, as I've said, helps more from cabling issues and might be a help in once in a while. But without the dual parity, the recovery might have been successful anyway. I sleep very well at night with the parity scheme. I have my own file integrity scripts, and don't have experience with that plugin - but YES, having a system for capturing checksums for all disks is very worthwhile. If something does go wrong, you have means to identify which (if any) files got corrupted. Since parity operates below the file system level, it is quite possible for silent corruption to creep in, evidenced by an occasional parity error. You have to compare the checksums when you see one of these happen to determine if something unexpected has corrupted a file (more typically, a parity error is only caused by a hard shutdown and parity, not the data disks, are the cause. Essential? Not the word I'd choose. A useful enhancement? Maybe. Would not much affect parity check times, which are based largely on the parity size (all the other disk I/O is happening in parallel). Freenas likely suffers from some of the same fundamental issues that unRAID does. Maybe there is no one over there able to point out the warts and wrinkles. I know the forum there is not nearly as active as here. If that's your preference - go for it. I really don't mind someone discussing specific features of competing products. But the ultimatums are annoying. Enjoy your array! (And if you move to Freenas - good luck!!)

Talk all you want. Just leave out the whining about moving to FreeNAS if it isn't implemented. If you want to make a difference, send a convincing note to LimeTech to tell them that this enhancement is more valuable to them than Ryzen / Threadripper enhancements and whatever else they are cooking in Colorado. I think if you want to go beyond 30, that you'd have a decent chance of getting the count increased. It's easy to increase the count. There was a bit of a challenge going past 26 (after sdz you go to sdaa (4 letters not 3), and that required some changes. But since that was overcome there are a lot of drives before you get past sdzz ). The questions I think that is in Tom's mind - how many drives is too many drives, and at what point am I not comfortable that my redundancy scheme is sufficient to protect my users' data. "I can" is different than "I should", and putting a loaded gun into his user's hands is not his goal. I think he cares - and I think dual parity is giving him confidence to continue to raise the drive count. I think 36 or even higher is possible in the future. As for 3 parity drives, he has said in the past that once you get past 2, the mathematics gets much more complex and performance would take a big hit. So I think that is unlikely. Plus I don't think it matters. It is too easy for Parity to get corrupted in the single disk failure model. And if one parity gets corrupted - ALL parities get corrupted. It's not like an independent mechanism. I personally think 2 parities is not very useful even as you get into larger arrays. Someone called it preparing for a plane hitting your house. I think that's pretty accurate. Let's take an example. Let's say the chance of a drive failure in an array in one year is 50%. And let's say there is a 5% chance of a failure corrupting parity. And that it will take 2 days to recover from a failure (if you can). So you have a 5% chance of data loss from corrupted parity, and a 0.26% of a second failure occurring during the 2 days you are trying to recover. So the second parity has reduced your risk of data loss from 5.26% to 5.015%. Third parity - it could reduce the risk by another .015%. Remember that one parity is protecting you from 94.73% of disk failures. Is it worth the cost of another 8 or 10TB drive to gain another 0.26%? How about that 3rd parity? The flat 5% risk of a failure corrupting parity can never be reduced. And these are some pretty conservative numbers. They discount single drive recovery efforts - that have a VERY high chance of success. I''ll leave it to the reader to decide how much they're willing to pay for the small percentage improvement It was hoped that dual parity would provide triangulation - and if there was a parity error unRAID would be able to tell you what disk caused it. That would be great info, and I beleive that the data is there, just needs some high order math to figure it out. But knowing the disk would be helpful. And then there is the holy grail - a tool that would tell you, based on a sector on a disk, what file was impacted. With these two features, dual parity would be hugely useful. A parity error could be traced back to a file! But in its current implementation, it isn't worth the cost of the drive to me. But that's me. I've been using unRAID for almost 10 years, know most of the tricks, recovered from numerous nasties. For a new user that has cabling issues, no hot swap bays, and doesn't know what they are doing, dual parity can provide SOME protection them from things that have nothing to do with drive failures. This is actually a much more valid use case. NEW USERS SHOULD HAVE DUAL PARITY, but they might consider eliminating it once cabling is secure, hot-swap cages are in place, and the risk of self inflicted wombs is lessened. As for multiple parity pools - I think its a good idea - better than dual parity as currently implemented. But I think it would be very difficult to implement - and even though I think it is a good idea, I don't think I'd actually use it. And then there are questions like - would user shares work across the pools? Or be separate? Or user gets to choose? Would they start and stop independently. How about Dockers - two different sets with independent settings? VMs? All gets complicated. Is it worth it? My vote would be no. Set up a second server if you need more than a 300T array. I'd much prefer the triangulation features.

I really don't think the reason multiple unRAID pools are not supported is due to profit motive. The number of drives supported by unRAID has steadily increased. When I bought it was 16. Why would LimeTech continue to increase the count without raising the price? And they recently implemented Docker and VM functionality. It would have been easy for LimeTech to EOL unRAID, and release "unRAID Ultimate" or something, that includes NAS and the Docker/VM functionality. LimeTech had had ample opportunity to monetize the relationship with existing customers but has consistently NOT done so. I think the issue is two fold - one technical and the other demand. unRAID utilizes (some might say cannibalizes) the software RAID feature of Linux for unRAID. I think bending it to support multiple pools may be complex. And, frankly, we don't get many users that want that many disks in a their server. If you want to use a different product - have at it. I did my homework and bought unRAID. And have never had a reason to look elsewhere. If FreeNas has the features you want, buy all means use it. The forum is not really the place for messages such as this one. LimeTech infrequently monitors posts unless in the release threads and if escalated to them. Feel free to send a PM or email to them.

If you want to manually rearrange data as you move it off of a drive to other drives, I'd recommend moving. Then you know what you have already copied off and what is remaining. If you are just copying all off one disk onto another, copying is faster. Among its other "features", RFS deletes are particularly slow for big files. So avoiding the delete is worthwhile!

Thanks CHBMB and the Medusa team! That worked. For anyone else trying to use these instructions, there is a very minor omission. Between the "git clone ..." command and the "sudo docker restart ..." command, you need to enter "exit" to get out of the docker. Thanks again!!!

I accidentally clicked the update button to update my Medusa container. Is there a workaround? The Docker log file shows ... [cont-init.d] 10-adduser: exited 0.[cont-init.d] 30-install: executing...Cloning into '/app/medusa'...fatal: could not read Username for 'https://github.com': No such device or address[cont-init.d] 30-install: exited 0.[cont-init.d] done.[services.d] starting services[services.d] done.python: can't open file '/app/medusa/start.py': [Errno 2] No such file or directorypython: can't open file '/app/medusa/start.py': [Errno 2] No such file or directorypython: can't open file '/app/medusa/start.py': [Errno 2] No such file or directorypython: can't open file '/app/medusa/start.py': [Errno 2] No such file or directory

BTRFS is stable enough, but it is much more susceptible to corruption if you have dirty shutdowns. I would recommend XFS unless there is some specific feature of BTRFS you need. And if so, make sure you have a UPS that is appropriately configured. But do some story and make sure you understand what BTRFS is and does. Must people here, i'd say 95%+ are on XFS. I would not loose any sleep worrying about bitrot. I'd be much more concerned about disturbed cables after swapping out ageing a disk, a real problem that causes data loss that you can and should proactively avoid by using hot-swap cages.

No problem running multiple preclears in parallel. Depending on buffer size, memory, and HBA bandwidth, you might want too limit to a reasonable number, but 2-4 should typically not be a problem.

Look at the Antec 900 (or similar case with 9 5.25" slots in the front), and install 3 SuperMicro CSE-M35T-1B 5in3 drive cages. That would give 15 hot swap drive slots. This would make it incredibly easy to add and replace drives over time without risking knocking cables loose, which is the most common problem users have.

Might want to look here: https://www.backblaze.com/blog/hard-drive-benchmark-stats-2016/ https://www.backblaze.com/blog/hard-drive-failure-rates-q1-2017/ The 6T REDS don't have the best stats, at nearly 3% failure rate. The Seagate 8Ts are looking pretty good, and look at how many they bought! (That's usually a sign of a good value drive). They are not the archive version (at first I thought they were but they are not). Seagate was sued for quality issues and since their quality has improved. The HGST 8Ts are stellar, but they only bought a few because they were the Helium drives and high dollar. There is nothing out on the WD 8T or 10T REDS. I can tell you as a brand name the HGST have been the highest for some time now, and I tend to buy them. But Seagates were 3 for the price 2 HGSTs (24T for the price of 16T). So it was hard to resist. May pay for it in reliability, though, but it was a calculated risk. The archives are good performers. 5900 RPM and high density. There is a possibility of it slowing down due to excessive random writes, but with media data it is normally sequential and the slowdown should never happen. Many users here use them successfully, even for parity, and report they work great. These are not recommended for RAID, but unRAID is not RAID. Not trying to sell you on anything, just providing info.

10TB drives are pricey. Maybe you already have - but might suggest looking at the 8T Seagate Archives. Shucking externals would get you to $180 each. Especially when you start thinking about the cost of single vs dual parity, it matters. Perhaps that could save enough money to buy 8x 8TB drives instead of 5 10T, and keep those 8 3T drives for backups. That would bring your drive count down from 28 to 23, allow you to backup 24T of data, for about the same price. HGST 8T are another option. HGST is the reliability king. A lot of people here love the Reds, but my experience has not been that stellar.

If instead of dual parity, if you loaded up a disk of exactly that size with your most important data, and put that in a safety deposit box or even at a friend or family member's home, you'd have made more valuable use of that space than dual parity IMO. Of course if you have that or equivalent already, then dual parity is not a bad idea for a 28 disk array!