SSD

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!

I am bjp999, not bjp2006! With 28 drives I think dual parity is worthwhile, although i would stop short of saying absolutely necessary. Being here for a long time I've seen a lot of issues, and very very very few where dual parity would have helped. The vast majority of issues are related to bad or loose cabling, and worse yet, users that don't recognize that is what is going on and make matters worse. If you have drive cages, solid wiring, monitor smart reports, and periodically replace drives as they get old, I could argue that dual parity is a nice to have and not a necessity. And lacking those things, I'd recommend those things before putting dual parity in place. And I'd also say 28 drives is a lot. If you have strung together a fleet of aging small drives, and assembled into a large array, I don't recommend it. But if they are relatively large, modern drives it should be fine. unRAID does not give up, from what I understand (never had it happen myself). It would continue to rebuild on a best effort basis. Unfortunately, even if you knew that it had happened due to a log entry, you'd have not way to know what file was impacted unless you kept checksums. I'd say this is very different than a RAID rebuild, one error and it stops and invalidates the array. Maybe good for an enterprise where the requirement for absolute data integrity is paramount. But not for a media array, where you'd rather have a randomly corrupted JPG than be pushed into doing a full array restore.

I guess it depends on the definition of "bitrot". If bitrot means that data is returned by a drive that is different than the data that was actually written (due to decay of the signal on the media, not due to something like bad cache in the drive), I agree with you. But if bitrot is related to the gradual degradation in magnetic signal on a disk making that data harder and harder to read over time, I DO think that indeed does happen - and is, in fact, is happening on a continuous basis. And real "bitrot" is when the degradation reaches a point where the data cannot be reliably read even with the error corrections built into the drive, causing the drive to have a read error. The question then becomes, at what point has the signal degraded to the point that it becomes unreadable? Is that a year, 5 years, 25 years, 100 years? 1000 years? Is it consistent across the media, or are some spots weaker in magnetic material. Or are some heads less sensitive imprecise in head placement to make a less than perfect signal on the disk harder and harder to read and correct. When we rebuild a disk, we are in fact re-writing every sector. This, in itself, would help us protect against bitrot. In the old days, Spinrite had a mode where it would do exactly that - rewrite every sector on the disk with exactly the same data. But I agree we have not seen anything we can ascribe the bitrot in the unRAID forums. So have to believe the timeline for the magnetic decay to be pretty lengthy, at least 7-8 years. But if one were worried about it, they could rebuild each disk onto itself or around its 3rd or 4th birthday, and feel better that the signal is refreshed and bitrot pushed out in time. Who knows, drives may start working harder and harder in the presence of magnetic degradation, prior to true bitrot, triggering retry cycles we are not even aware of, and adding wear and tear to the drive. (Of course drives that are continuously updated with new files would be less susceptible to bitrot, although perhaps become susceptible to bitburnout, a very different phenomenon! )

@shEiD @johnnie.black @itimpi Oh how we love to be comforted! While it is true that the mathematics show you are protected from two failures, drives don't study mathematics. And they don't die like light bulbs. In the throes of death they can do nasty things, and those nasty things can pollute parity. And if it pollutes one parity, it pollutes both parties. So even saying single parity protects against one failure is not always so, but let's say it protects against 98% of them. Now the chances of a second failure are astronomically smaller than a single failure. And it does not protect in the 2% that even a single failure isn't protected, and that 2% may dwarf the percentage of failures dual parity is going to rescue. I did an analysis a while back - the chances of dual parity being needed in a 20 disk array is about the same as the risk of a house fire. And that was with some very pessimistic failure rate estimates. Now RAID5 is different. First, RAID5 is much faster to kick a drive that does not respond in a tight time tolerance than unRaid (which only kicks a disk in a write failure). And second, if RAID5 kicks a second drive, ALL THE DATA in the entire array is lost. With no recovery possible expect backups. And it takes the array offline - a major issue for commercial enterprises that depend on these arrays to support their businesses. With unRaid the exposure is less, only affecting the two disks that "failed", and still leaving open other disk recovery methods that are very effective in practice. And typically our media servers going down is not a huge economic event. Bottom line - you need backups. Dual parity is not a substitute. Don't be sucked into the myth that you are fully protected from any two disk failures. Or that you can use the arguments for RAID6 over RAID5 to decide if dual parity is warranted in your array. A single disk backup of the size of a dual parity disk might provide far more value than using it for dual parity! And dual parity only starts to make sense with arrays containing disk counts in the high teens or twenties. (@ssdindex)

Just watched part2 last night. Great video, as always! A couple questions / comments: 1 - I know that unRAID prefers core0, so as a result I had avoided pinning VM cores there. In an earlier incarnation of unRAID VM a couple years ago (Xen), there were cases where core0 would get overloaded and unRAID would starve and fail. Is that a concern with KVM? Assuming no, I will start using core0 for VMs. (I had not been assigning Dockers by core or load, but may start to look at that). 2 - We continue to recommend that cores be pinned with their hyperthreaded twins. There are cases where multiple cores cause problems, and I can only pin one logical core. Does it matter whether pinning core0 vs its twin? What is the negative of assigning one VM to one core, and another to its twin? (I know its not recommended, just don't understand exactly why and if you had done any testing.) 3 - Very interesting approach of having multiple Docker containers linked to same appdata. (I had done this when moving to a different Docker for the same app). Makes sense to have a "High Transcode" configuration for Plex! You'd want to update to the next version in tandem (although you could update one, check it out to make sure it is working properly, and only then update the other). And be careful to not let them run together, as you said. Thanks!

Why? Inside the VM you'd be able to access the disk using SMB. Since it is local to the same machine, it is quite fast. But if you really needed to pass it through this would not be the place to ask. Check out SpaceInvader One's (on youtube) videos on passthrough. I know you can pass through a SATA controller and pass the disk through that way. Not sure if you can just pass through a single disk.

The whole idea of Dockers is that they contain functioning code and no configuration data. With the docker templates stored on your flash, you can rebuild them very fast. I recently recreated my docker on a fresh SSD. Took about 10 minutes. I'd focus your backups on your irretrievable data. I'd probably including the "appdata" share on the cache, at least for some Dockers. If you have VMs (domains share), you might want to periodically back them up as well. But they can be big and it really depends on how much time it would take you to reconstruct. Even with VMs, you should be externalizing your data onto the array so backing them up may very well not be necessary, at least not very often.

Hey - we all give our time. Have any idea how many hours I put into unmenu/mymain? The faster preclear script? The wiki? I've handled some of the most complicated data recovery scenarios in the forum taking hours of research and extensive step-by-step instructions. I'm not demanding anything of anyone. I just made a suggestion - anyone should be able to do that - and expect a minimum of a friendly response thanking for the insight. @johnnie.black also has requested the use of the unRAID disk format. It would be quite useful and users would benefit. @dlandon - thanks for your excellent contribution on UD. Putting it all together into this plugin is quite a lot of benefit to unRAID users. On this topic, we'll just agree to disagree. Peace.

You're a hard man @BRiT! But it is a fair point and I agree with you this far - users should have backups of their critical data. But problem is, many do not have backups at all. And even those that do, may not backup voluminous data that is "recoverable in other ways", that they take a calculated risk they'd never have to recover. Does that mean the support forum should not promote an option to maximize the value of unRAID and offer the very best chance of recovering the data? And give the user the control to decide which data is most valuable and direct that it be the priority to recover? Offering such a user a way to put in a new disk, partition and format it so that it could be added into unRAID later, and using Krusader, mc, cp, or something else to copy the data over in a selective manner, is what I would be advising. And today, in order to give that option, I need to explain a complicated multi-reboot process to format their new 8T drive for unRAID and mount it outside the array. I'd rather explain to install UD, do these three clicks, and they are ready to go. If the array is too far gone, and the user doesn't have backups, shame on them. But if the array is recoverable to at least some degree, and we as the support forum do not make the option available to give them the best chance of recovery, shame on us. That's how I feel anyway.

I never said that I didn't trust unRAID to rebuild a disk. Or I was desperately in need of this feature (I explained three ways to do it!) Please reread my post. I think I articulated my use cases pretty well. And made a reasonable suggestion. You can take it or leave it, but I'd prefer you didn't insult the idea and tell me my its not worth your time. And I asked not on behalf of myself. And I am not even a UD user! I just think it belongs in UD. Your users do not know of your decision to partition disks incompatible with unRAID disks. A number of users have used UD to format disks, and then copied data to them, only to find out they can't and having to redo a lengthy set of operation. They are mystified and blame unRAID because they don't know enough to trace it back to you. And I believe for no good reason except it wasn't worth your time to understand the unRAID partitioning and formatting commands. How would you have a user with a 2011 vintage array with 4 disks showing reallocated sectors, one drive dropped from the array, and priceless (from their perspective) data to recover? Add dual parity? (ROFL) Scenarios like this has happened 2-3 times in the last couple months. My suggestion would help those users who you refer to as edge cases. Later.

When helping people with some tricky array problems, being able to have a get them to prepare an unRAID compatible disk would be useful. This is particularly needed with older arrays demonstrating multiple drive issues. I'd rather not have them do multiple rounds of rebuilds, but instead copy the data to new disks and then form a new array when complete. I also have a relatively frequent need. I will often buy a set of new drives (say 2 8T drives), that I want to use to replace several smaller drives (say 3 4T drives). I want to install the 8T drives outside the array, copy the data to the new drives, run md5 comparisons and ensure all is good, and then do a new config excluding the 4T drives and including the 8T drives with a single parity build. The I/O to the unassigned drives is fast. And the array only has to do one rebuild cycle. And I am free to shuffle the content as desired. Any disk fragmentation is taken care of with the fresh copies (unlike a rebuild that "inherits" the fragmentation). And I am left with the 3 4T drives with data intact that I can use for backups. Doing this in other ways is more complicated and time consuming, and overall more disruptive to my usage. (I do take add'l precautions to monitor smart reports and run a parity check soon before the exchange to protect against failure during the rebuild, and have other techniques to recover even if there is a failure during the build.) Formatting in unRAID format is not THAT difficult without this feature. The cache slot can be used - but if you have a cache drive or cache pool supporting VMs and Dockers it is not so obvious that you can do so without creating a problem for yourself. But I recently did exactly that with my single cache drive that contained a set of Dockers. Replacing it with a real disk that I wanted to format disabled docker functionality. After formatting it, I stopped the array and install the next disk to format, until all disks are formatted, And re-installing the correct cache drive everything was put right. I have not tried with cache pools or with VM feature enables, and would not wholeheartedly recommend this method if you are not confident in your ability to recover if things went wrong. Another way is to use a trial key. This is foolproof but a bit of a PITA. A good way, IMO, is to create a temporary config folder on your real USB key, and boot with that. With the array stopped, rename the config folder (e.g, "config-real") and create a new "config" folder. Copy the primary config files, like ident and network and disk, as well as your USB-specific ".key" file. No "super.dat" file. But have no plugins or other stuff that might confuse things. And no super.dat (although that is not really a problem if you include it). You can boot, create an "array" of the few disks to format, format the disks, stop the array, rename the config folder to "config-format" or something, and rename the "config-real" to "config". When you reboot all is as it was, except the disks are formatted. UD works great with the disks formatted like this. And unRAID is happy with them as well. I believe this would be a nice enhancement to UD to avoid all this rebooting and renaming, and make these techniques easier for users.

Forgive if this has been asked before. But would it be possible to make unassigned devices partition and format disks in an unRAID compatible format? There are a lot of use cases where being able to create a compatible disk would be very handy, and instructions to do so can get complicated (e.g., booting a trial version).

Deserves to be. Thanks!!

@Squid- Add to CA? Thanks!

Sounds like an interesting setup. How does it cool? I have a 92mm fan in each of 4 drive cages, pulling air in over the drives, and several case fans evacuating. My cooling is very good, with parity check temps maxing in upper 30s, and occasionally lower 40s on warmer days. (That's with 20 drives). Your fans should be generating negative pressure in the case, but I'd be a little concerned that air would flow through least resistance and with air currents some of the tighter spots would have lesser flow. Do you have some drives that run hotter than others? Also, not all fans have enough umph to generate enough pressure to move a lot of air against significant resistance. And the ones that do are not the quietest. What is your criteria for exhaust fans? My server lives in an unfinished basement and quiet is not so important. A beefy fan in each cage really works well. But many users need a very quiet server and your method sounds a good way to go!