June 5, 200818 yr For those that need RAID1 today, you can do it with hardware and the steelvine processor. Frankly I would prefer it in unRAID itself so drive spin down would work.. In the meantime there is hardware to help.
June 5, 200818 yr What are you trying to do with the extra parity / mirroring / warm spares / hot spares / rebuilding onto your cache disk ... features? Some of these improve RELIABILITY and some improve AVAILABILITY. If your goal is to improve reliability, you need to seek out the most likely failure and address it. For example, if the risk of spontaneous combustion is 10% and the risk of a drive failure is 1% (silly example I know), then reducing the chance of disk failure by 100x reduces your overall risk by less than 1% from 11% to 10.01%. Not much. But if you were able to reduce the risk of spontaneous combustion by half to 5%, you'd reduce your risk by almost half (from 11% to 6%). If your goal is to improve availability, you need to realize that you will be sacrificing reliability to do so. As in the post that RobJ referenced (thanks by the way), repeated here http://lime-technology.com/forum/index.php?topic=1731.msg12108#msg12108, if the root cause of your failure was your exhaust fan failing, the worst thing that could happen is you suddenly spin up all your drives and start trying to rebuild. The excessive heat could cause other drives to fail and take years off the lifetime of the others. Setting that up just cost you reliability. For me, RELIABILITY is FAR more important than AVAILABILITY. I wish that unRAID would do as little as possible when it detects a problem and let me know that a problem has occurred. (This is outlined in the other post). I do not have users depending on my unRAID to serve production uses. Worst thing that could happen to me is that I have to use a DVD disk (heaven forbid) rather than playing the move from unRAID! I have a lot of important data on my unRAID - data I really don't want to lose but not worth the time and effort and cost to back it up. Reliability is king! Users have to realize how incredible unlikely 2 simultaneous disk failures are (http://lime-technology.com/forum/index.php?topic=1751.0). Trying to address such a statistically small risk is just not worth it IMO. My experience with over 25+ years building my own computers (first one was in 1984 - an 8088 running at 8MHz), the most common cause of system failures is HEAT. The single smartest thing people can do is add a fan or two to their systems blowing across / between their drives. This $10 solution will do more for your reliability than all the hot spares in the world! Just my $0.02.
June 5, 200818 yr RAID1 on the cache disk provides RELIABILITY and AVAILABILITY. If we're going to possibly end up running third party addons from this drive, it's a necessary situation. As far as simultaneous drive failures... I've seen not seen simultaneous failures, but I have seen failures within a week of one another 4 times in the last 3 years. This most often happens when you buy a batch of drives from the same vendor at the same time. 3 servers had similar problems because we purchased 4 drives each for a raid10 array per machine. The drives started failing within a week of one another after going live. We were swapping drives like mad until I told my partner to stop buying the 250G drives from vendor A and bite the bullet and buy the 300G drives from vendor B So possibility exists. Especially for the average unRAID user who takes any spare drive and builds an array. Then again, this is unRAID's strength. To get the last ounce of use out of every drive LOL!!! Heat is a very high factor in failures. I've not seen a situation where a drive failed by heat and a person did not know it was coming. If they did not know it was coming then they are not conscientious about maintaining their equipment. > The single smartest thing people can do is add a fan or two to their systems blowing across / between their drives. This $10 solution will do more for your reliability than all the hot spares in the world! Fan's running, or airflow, across the drives are a mandatory... This is a given. especially when you have an array of drives. Anyone not doing this is just waiting for a problem, daring it to occur. So I don't believe it's just a $10 solution. It's a mandatory part of any array. It also veers the subject off topic. Will it do more for reliability, Yes, Does it help availability yes. But I think a warm spare is a necessary evil if you want higher availability. Stated in bjp999's usage.. "Worst case is I mount a DVD" In my case, I'm moving many machines data onto my unRAID server. It's becoming a central part of my environment. Higher availability means allot to me. Especially as I remove spindles from my other machines and mount them over network from a centralized file server. Please don't belittle the possible uses here. For some it's just a lil media server for others it's a central support server. Lack of some features and a tunneled/short sighted view of what unRAID can be used for will keep it small and out of a larger environment. Unless that is all that anyone plans to do with this environment. > If your goal is to improve availability, you need to realize that you will be sacrificing reliability to do so. Poppycock I say. With High Availability comes Higher Reliability. What sacrifice? In the case presented with a possible overheat. You have neither reliability nor availability because the heat condition will cause you to power down the machine. The only way to improve reliability is to have fans and have a software layer monitoring temps with an event handler to do something about it. Higher availability comes when you add fans that are heat sensitive and can spin faster to take up the slack. Does a hot spare help in this case, no because the root cause has nothing to do with the drive and everything to do with a failure of some environmental condition. There is no sacrifice of reliability for availability. > if your goal is to improve reliability, you need to seek out the most likely failure and address it. let's consider.. what is the most likely failure... Ummm from what I can see.. a drive fails... and how do we address it. unRAID goes into parity phantom support mode whereby it provides the failed drive in a phantom arrangement. How do we fix the issue, usaually replace the drive. How do we do it attended. replace or Re-assign the drive to warm spare How do we do it unattended, Assign a hot spare. Let unraid rebuild on it's own... It's a person's choice.. Is this sacrificing reliability? If the core issue is heat, then it should have been handled at a different layer before a drive failed. > I wish that unRAID would do as little as possible when it detects a problem and let me know that a problem has occurred. Well it does that now. Only, it doesn't really let you know a problem has occurred. This is a really big peeve of mine. You don't really know something has gone wrong without getting under the hood. No mail alerts, no active log warnings on the front end. It's designed to be easier for novices, but then you have to get them to the command line to do anything anyway. Don't take my comments too personally. I just don't want things to be clouded up in relation to one persons use over another. I'm going to have to be convinced allot more that adding availability sacrifices reliability.
June 5, 200818 yr I wish that unRAID would do as little as possible when it detects a problem and let me know that a problem has occurred. (This is outlined in the other post). I do not have users depending on my unRAID to serve production uses. Worst thing that could happen to me is that I have to use a DVD disk (heaven forbid) rather than playing the move from unRAID! I have a lot of important data on my unRAID - data I really don't want to lose but not worth the time and effort and cost to back it up. Reliability is king! I agree 1000% If there is a folder, or a disk that has data so critical to you that you can not ever replace it, then set up a similar folders on two other data disks and use rsync to keep them all in sync. You could set up a cron task to sync them hourly, daily, whatever. Now, with that in place, you are protected against two drives failing. (Since the folder is on THREE separate physical drives, all three would have to simultaneously fail to lose your data. Can three failures happen at the same time, sure... all it would take is a fire/flood/tornado/direct lightning hit. Is it likely, no. You still need to do backups... and keep the backup elsewhere. I agree with bjp999. If a disk fails in my array I can react in many ways. If I am in the middle of watching a movie, with a room full of guests, the last thing I want is for unRAID to decide to shut itself down. When guests are gone, and the movie over, I can shut the whole server down if need be, and get a DVD off my shelf, but I want that to be my choice. My "Spare" 750 Gig drive is installed in one of my MG-35 media players. Yup, it has over 100 movies to use when in the car and not connected to my LAN. As long as I am not traveling, and the MG-35 is connected to the bedroom TV, it is as good a place as any for a "semi-warm" spare. I can always order a replacement for the MG-35 when I see a good sale since it is just fine without any installed hard disk as long as it is connected to the LAN. A lot depends on how you use your unRAID server. If just for media, then it being off-line is not an issue. If it has files critical to your business, then a "warm-spare" is inexpensive insurance, and some day, a "hot spare" feature desirable.
June 5, 200818 yr > I wish that unRAID would do as little as possible when it detects a problem and let me know that a problem has occurred. Well it does that now. Only, it doesn't really let you know a problem has occurred. This is a really big peeve of mine. You don't really know something has gone wrong without getting under the hood. No mail alerts, no active log warnings on the front end. It's designed to be easier for novices, but then you have to get them to the command line to do anything anyway. The lack of any notification when failures occur is exactly why I developed the e-mail and LAN based notification scripts. Otherwise, as you said, you have to keep an eye on its management page to know if anything is going on that needs attention. Tom really needs to add e-mai notification as a standard part of unRAID. (After UPS support, NFS support, NTFS-3g, etc) Joe L.
June 5, 200818 yr The lack of any notification when failures occur is exactly why I developed the e-mail and LAN based notification scripts. Otherwise, as you said, you have to keep an eye on its management page to know if anything is going on that needs attention. Tom really needs to add e-mai notification as a standard part of unRAID. (After UPS support, NFS support, NTFS-3g, etc) Joe L. I have packages which do this using exim. it's small and lightweight. The hard part is where to define where the mail goes. In my package right now it gets piped into logger so it gets into syslog. (for now). However if you install it with [email protected] /boot/custom/etc/rc.d/S20-install-exim Then it will set up an alias to forward all mail to the stated MAILTO. Once this is done, Simple batch/at/cron jobs can be used to check the status of events and cron w/exim will mail the results. I have not seen a response from Tom to my Mail Transfer Agent thread. In order for this to work smoothly, there needs to be a user configurable field in the web interface. This whole edit your go script has got to go. I'm veering off topic.. So I'll leave that to another thread.
June 5, 200818 yr The lack of any notification when failures occur is exactly why I developed the e-mail and LAN based notification scripts. Otherwise, as you said, you have to keep an eye on its management page to know if anything is going on that needs attention. Tom really needs to add e-mai notification as a standard part of unRAID. (After UPS support, NFS support, NTFS-3g, etc) Joe L. n order for this to work smoothly, there needs to be a user configurable field in the web interface. This whole edit your go script has got to go. I'm veering off topic.. So I'll leave that to another thread. I agree... directly editing "config/go" is fine for the more technical user, but not for most people who use unRAID. In fact, for some of them, "notepad" is a new experience, and a unix/linux prompt a complete mystery. Joe L. So many tasks... with just one developer. Imagine if Tom enlisted others to help . Perhaps when he is rich and famous he can hire a few of us.
June 6, 200818 yr RAID1 on the cache disk provides RELIABILITY and AVAILABILITY. If we're going to possibly end up running third party addons from this drive, it's a necessary situation. I guess I could see mirroring the cache disk. It is the only part of the array without redundancy. As far as simultaneous drive failures... I've seen not seen simultaneous failures, but I have seen failures within a week of one another 4 times in the last 3 years. This most often happens when you buy a batch of drives from the same vendor at the same time. 3 servers had similar problems because we purchased 4 drives each for a raid10 array per machine. The drives started failing within a week of one another after going live. We were swapping drives like mad until I told my partner to stop buying the 250G drives from vendor A and bite the bullet and buy the 300G drives from vendor B Statistically, new drives have far higher failure rates than those that have burned in for a while. So possibility exists. Yes Especially for the average unRAID user who takes any spare drive and builds an array. Then again, this is unRAID's strength. To get the last ounce of use out of every drive LOL!!! Can't agree here. "Especially for the average ..." you are the ONLY user I have found here that has witnessed near-simultaneous drive failures. I'd say it is more likely for a professional like you buying lots of new drives and putting all in service at the same time. Heat is a very high factor in failures. I've not seen a situation where a drive failed by heat and a person did not know it was coming. If they did not know it was coming then they are not conscientious about maintaining their equipment. How many smart test files have you seen with temps 45C+. People are not conscientious about keeping their equipment cool. You are. I am. Getting people to understand this threat is important. I perceive that the same users that are having heat problems are also asking for these warm/hot spare and extra parity solutions. My point was FIX THE HEAT ISSUE FIRST. If you're going to do the spare thing, do it because you've already done all the easy things that prevent more likely failures. Fan's running, or airflow, across the drives are a mandatory... This is a given. especially when you have an array of drives. Anyone not doing this is just waiting for a problem, daring it to occur. So I don't believe it's just a $10 solution. It's a mandatory part of any array. It also veers the subject off topic. Preaching to the choir with this comment. But it is not mandatory. It is likely not even common. Most people are running their drives in hot cases and wondering if slapping another drive in there at 47C wouldn't be a great idea to provide extra redundancy. Fix the basics first - then get fancy. This is clearly a good "feature" available to all. (Sorry if off topic, iin my mind this is all twisted into a single issue.) Will it do more for reliability, Yes, Does it help availability yes. But I think a warm spare is a necessary evil if you want higher availability. Stated in bjp999's usage.. "Worst case is I mount a DVD" I was upfront about my uses for unRAID. I care more about reliability. I understand that your usage patterns are different than mine. That's okay. I have nothing against having these features - they are likely a good idea for users needing high availability. But Joe User who uses the array a few times a week to play a few movies and do a backup or two is not going to be terribly inconvenienced by an outage for a couple of days. You are different - you need the availability for good reason. You are very different from most users here. But the truth is, true simultaneous drive failure is something that most us would never have to deal with in our lifetimes! In my case, I'm moving many machines data onto my unRAID server. It's becoming a central part of my environment. Higher availability means allot to me. Especially as I remove spindles from my other machines and mount them over network from a centralized file server. Please don't belittle the possible uses here. For some it's just a lil media server for others it's a central support server. Lack of some features and a tunneled/short sighted view of what unRAID can be used for will keep it small and out of a larger environment. Unless that is all that anyone plans to do with this environment. Understood. If folks like you are a significant segment of the unRAID population, or if adding these features would attract more iusers, I absolutely support having these features. > If your goal is to improve availability, you need to realize that you will be sacrificing reliability to do so. Poppycock I say. With High Availability comes Higher Reliability. What sacrifice? In the case presented with a possible overheat. You have neither reliability nor availability because the heat condition will cause you to power down the machine. The only way to improve reliability is to have fans and have a software layer monitoring temps with an event handler to do something about it. Higher availability comes when you add fans that are heat sensitive and can spin faster to take up the slack. Does a hot spare help in this case, no because the root cause has nothing to do with the drive and everything to do with a failure of some environmental condition. There is no sacrifice of reliability for availability. > if your goal is to improve reliability, you need to seek out the most likely failure and address it. let's consider.. what is the most likely failure... Ummm from what I can see.. a drive fails... and how do we address it. unRAID goes into parity phantom support mode whereby it provides the failed drive in a phantom arrangement. How do we fix the issue, usaually replace the drive. How do we do it attended. replace or Re-assign the drive to warm spare How do we do it unattended, Assign a hot spare. Let unraid rebuild on it's own... It's a person's choice.. Is this sacrificing reliability? If the core issue is heat, then it should have been handled at a different layer before a drive failed. Poppycock? ;D Having the computer doing automatic operations can cause problems. If it decides to rebuild a failed drive, and the rebuild fails because of a PSU failure or a MB failure or a heat issue or anything else, you could have made the problem worse. If you had run diagnostics and found the culprit, the failed rebuilt is averted. Likely - no. Possible - yes. You can't just say if it was a heat issue you have to ignore it because it wasn't the drive's fault. High availability makes at least subtle reductions in overall reliability to keep the array up longer This is not a bad thing - just reality. On the flip side, poor reliability negatively impacts availability at the same time. No argument there. > I wish that unRAID would do as little as possible when it detects a problem and let me know that a problem has occurred. Well it does that now. Only, it doesn't really let you know a problem has occurred. This is a really big peeve of mine. You don't really know something has gone wrong without getting under the hood. No mail alerts, no active log warnings on the front end. It's designed to be easier for novices, but then you have to get them to the command line to do anything anyway. When things get bad I want the server to shut down. That is my cure for most things. Let there be a setting to force the box to stay up even under an otherwise warning condition so you can get in to do diagnostics. An automatic shutdown sends a clear message that something is wrong! Almost as good as an email! Don't take my comments too personally. I just don't want things to be clouded up in relation to one persons use over another. I'm going to have to be convinced allot more that adding availability sacrifices reliability. These kinds of discussions are why I come here! No offense taken. You've made a good case for having Tom implement warm / hot spares for high availability needs. I now agree that these features should be added. But users should look to implement these IN ADDITION TO good cooling, not as a replacement. Cheers!
June 6, 200818 yr I'll have to agree with you here.. I'm not the average user. But I also bring behind me lots of "non average users". These users scoff at the current environment because of it;s infancy and inability to handle itself well vs other "free" solutions. Can't agree here. "Especially for the average ..." you are the ONLY user I have found here that has had simultaneous drive failures. I'd say it is more likely for a professional like you buying lots of new drives and putting all in service at the same time. Again, I'm not the average user, but if you look at some of the comments on newegg, you will see there are waves of comments whereby people will have batches of bad drives. As it is, I bought 4 drives over the course of 3 months, 1 died right away, the other failed a week later. the one the died was a week old, the one that failed was 3 months old. My point was FIX THE HEAT ISSUE FIRST. [/quiote] Could not agree more. then again, I think more people are aware of heat then you give credit for. In addition, the webUI should do like readyNAS and warn you of high heat. In addition the READYNAS will tell you the SMART Health status. So far your the first person I met who wants the machine to turn off when a problem occurs instead of sound an alarm post a notice. As it is, syslog is not saved, how would you know why the machine turned off. For me, I forward all syslog messages to a log host so I would know, but would you question, why your machine turned off if it did? You are different - you need the availability for good reason. You are very different from most users here. True, but as I mention above, I had allot of "professional" people setting up home nas, so I'm different from people here, but average with people I deal with. Having the computer doing automatic operations can cause problems. If you start to rebuild a failed drive, and the rebuild fails because of a PSU failure or a MB failure or a heat issue or anything else, you could have made the problem worse. If you had run diagnostics and found the culprit, the failed rebuilt is averted. Likely - no. Possible - yes. You can't just say if it was a heat issue you have to ignore it because it wasn't the drive's fault. High availability makes at least subtle reductions in overall reliability to keep the array up longer If you have heat issues and are not aware, nothing is going to save you. As far as automatic fix making the problem worse.. The problem is already as bad as it can be. Your machine/array over heated because of something not being warned or handled. This is why a good drive cage has alarms. Just because someone is not conscientious about monitoring heat doesn't mean the rest of the people should not have automatic rebuild if they want it. High availability makes at least subtle reductions in overall reliability to keep the array up longer This is only in the case of heat. and no matter what.... an overheating condition is already less reliable and has nothing to do with the high availability. You're blowing heat all over the discussion of high availability and spares ;D when in reality it's two different situations. If your machine is past a safe threshold, a warning should go off and/or the machine should shut down. A rebuild should not be triggered. An automatic shutdown sends a clear message that something is wrong! It's not clear enough, an email and a shutdown is clear'er You've made a good case for having Tom implement warm / hot spares for high availability needs. We have warm spare availability now. But for my high reliability needs, a cold spare (so cold that I don't even own it yet!) works for me. I'm on my computer 16 hours of the dy. I run an FTP site and an internet radio station. a cold spare I don't own would never work for me LOL!
June 6, 200818 yr WeeboTech - I slept on this and made some changes to my prior post. Might want to give a second read. You are not average and neither am I. We all want something different from unRAID. You want unRAID up all the time, sending you emails when things go wrong and performing designated self-repair activities while letting you know real-time what's happening. You are constantly using it in conjunction with your work / hobbies. Downtime is aweful. I leave my unRAID at home all day while I work. It is out of sight out of mind - located in my basement. It contains a ton of important data and I want it to take all precautions to safeguard its contents. I access the data occasionally. Kept cool, using good maintenance processes (monthly parity checks) and relying on the parity drive to protect me from failures, unRAID provides adequate availability and reliability for my needs. If something goes wrong, I'd rather it just shutdown than try to continue to operate or fix itself. If I got an email I likely will not be able to check on it for HOURS. Occasional downtime is no big deal. So we're on opposite sides of needing this feature based on usage patterns and needs. But I've listened and learned and you have convinced me that these high availability features are good things to have and will appeal to a wide range of users. Who knows, I may even be convinced to trust my unRAID box to do some of them (not likely, but you never know ). If I were Tom, considering the competition, I'd definitely be looking at these types of features and providing options to appeal to the widest possible user set. From people like me to people like you, and everyone in between! I do hope that your're right and users are not looking to add more drives to their arrays to provide redundancy INSTEAD of keeping the drives they have at low operating temperature. We both are in complete agreement on the need to keep the system and drives cool.
June 6, 200818 yr We are on different sides of the spectrum in usage. Mine is always on always accessed. Even when I am here at work. When I download source, I ssh to my machine at home wget it onto unraid, unpack and work on it. if I need to transfer files from that unraid to my local machine, I use lrz/lsz along with secure CRT. It's not just a media warehouse, It's my file server. As far as the debate, It's an interesting one. 2 Parity drives for protection (like raid 6) as this thread started... Hot Spare., Warm Spare. Cold Spare. I guess you would have to consider which provides the most bang for the buck vs development time. Right now, A warm spare suffices. However if the array capacity is enlarged I believe things would need to change. I.E. Another parity drive, Multiple Protected JBODS, or Hot Spare scenario. As far as overall operation and health, I believe more needs to be put into the unRAID environment and I believe we are both in agreement here. Veering off topic.... If I had my way, the first page would change. http://lime-technology.com/forum/index.php?topic=2110.msg15495#msg15495
June 16, 200818 yr You might find this interresting. http://kernel.org/pub/linux/kernel/people/hpa/raid6.pdf
June 18, 200818 yr Here is another link I found. It has much more info than the last one and includes a link to a UNIX C library that implements dual parity calculations using non patented GNU LGPL code. This quote describes what I believe is the greatest benefit of dual parity. "In recent years, RAID-6 has become important when a failure of onedisk drive occurs in tandem with the latent failure of a block on a second drive [CEG+04]. On a standard RAID-5 system, this combination of failures leads to permanent data loss." These documents include a lot of theory and math that I certainly don't understand but if you focus on the general descriptions and implementation of "Liberation Codes" there might be something here that actually makes it practical to add dual parity to unRAID. http://www.cs.utk.edu/~plank/plank/papers/CS-07-602.html If unRAID can be described is RAID5 without striping and a dedicated parity drive then unRAID6 could be RAID6 without striping and two dedicated parity drives. All the great features of unRAID could be retained along with no data loss in the case of a failed drive and latent block failure. I currently have an 8x250G RAID5 array that I am going to replace. I was planning to go RAID6 (already purchased a new 3Ware card) when I discovered unRAID. I really, really like the features of unRAID for a large media server but really don't want to deal with the rather high risk of not being able to recover all files after a drive failure. So I am still on the fence. If unRAID supported true dual parity it would be a no brainer. High availability that supports hot swap is a whole nother subject. For my purpose it is not necessary.
June 18, 200818 yr RAID 6 has been discussed in several ways here before, either directly or in statistical calculations about data loss, and my sense has been that there is very little interest here in RAID 6 or double parity. That may be because unRAID is not designed for the high performance, high availability, mission critical server crowd, but attracts more of the home server, light media server, and backup server user. One of the attributes of unRAID that reduces the risk of data loss compared to alternatives is, as you probably know, the fact that it is unstriped, and uses a standard and common ReiserFS file system. So if I have 8 disks and 2 fail, my worst case is data loss of 2 disks, and I can immediately restart the array and fully access 5 data disks. And if one of the disks that failed was the parity drive, then I only have one lost data disk, and can immediately access 6 good data disks. Another possible benefit of unRAID is its flexibility with the drives it serves. They can be mismatched in size, brand, age, speed, and install time, which tends to avoid the issue of multiple drives of the same batch failing nearly simultaneously, more of a problem in some of the other hardware RAID systems. This benefit is offset though by the fact that just because unRAID users can take advantage of their old drives, they may very well have an old drive near the end of its lifetime when some other drive fails. Rebuilding a drive requires total access to every sector of every drive, and one would prefer at that time to have full confidence in the reliability of all of the other drives, at least until the rebuild is finished. I only mention the benefit above, because it takes away a little of the fear of simultaneous drive failure. And I imagine that those with a hardware requirement to use near-identical drives do their best to avoid more than 1 drive from any one batch. Glad to have you here, and your contributions. That is very interesting math, and links to libraries, and perhaps Tom may decide in the future to invest in the coding time to add double parity support.
June 18, 200818 yr but really don't want to deal with the rather high risk of not being able to recover all files after a drive failure. If you have a spare drive, the "high" risk you mention, is minimized greatly. I had a disk fail recently. I stopped the array. assigned the warm spare to the failed slot, in a couple hours it rebuilt it. All done. I don't see unRAID being of any higher risk of drive failure then any other raid. In fact I see it as minimizing the loss of "all" your data in the event of multiple drive failures.
January 19, 200917 yr I would also like to see dual parity, several operations in unraid leaves you parity-less when you do them. And for the record, dual-parity can be implemented without striping.
January 20, 200917 yr I would also like to see dual parity, several operations in unraid leaves you parity-less when you do them. And for the record, dual-parity can be implemented without striping. I don't see how having dual parity helps with operations that leaves unRAID parity-less. Hot spare sounds good, right now I implement a warm spare... I.E. A drive sits in the array spun down. If I have a failure, I stop the array, re-assign the bad drive, and rebuild it onto the spare drive. Not sure how many people would want that automated.
January 20, 200917 yr I really hope dual-parity is high on his priority list of things to implement. There are a number of things that can happen that can corrupt parity as a drive is failing. It would not matter if you had 1 or 100 parity drives, they would ALL get corrupted and result in an inability to rebuild even one failed disk. If all disks failed like a light bulb - working one second and then dead as a doornail the next - this wouldn't be an issue. But drives don't fail that way. Having a second parity disk sounds great, and it would help protect in a case where 2 drives really did fail simultaneously, this has NEVER happened in any case reported on these forums for at least the past year. Although I am definitely in favor of this enhancement, it is not high on my list until we eliminate some of the more likely causes of data loss.
January 20, 200917 yr I would also like to see dual parity, several operations in unraid leaves you parity-less when you do them. And for the record, dual-parity can be implemented without striping. I don't see how having dual parity helps with operations that leaves unRAID parity-less. Hot spare sounds good, right now I implement a warm spare... I.E. A drive sits in the array spun down. If I have a failure, I stop the array, re-assign the bad drive, and rebuild it onto the spare drive. Not sure how many people would want that automated. I would not want it to be automated. I'd like to figure out what happened before having a hot spare take over the failed disk's space. If had a drive a month or two ago fail in unRAID and it was taken offline. After investigating (and asking on here) it turns out the drive just had an issued starting up that one time. Once I added that drive back to the array and did a parity check it passed with no errors. If I would have had a hot spare in place, that drive (that was fine) would have been replaced. I think the best solution with a warm spare is to have the server shut down when a disk fails. However, before shutting down, it could export the log and information about which disk shut down in the array to the USB stick. That way, if a drive fails while you're away from home, you don't have to worry about more disks failing until you get home to investigate the problem. Once you get home and see your server turned off, you could take your USB stick and put it in another PC to get the needed files off of it. This way you could figure out which drive failed on you, and possibly how/why/when it failed.
January 20, 200917 yr I would also like to see dual parity, several operations in unraid leaves you parity-less when you do them. And for the record, dual-parity can be implemented without striping. I don't see how having dual parity helps with operations that leaves unRAID parity-less. Hot spare sounds good, right now I implement a warm spare... I.E. A drive sits in the array spun down. If I have a failure, I stop the array, re-assign the bad drive, and rebuild it onto the spare drive. Not sure how many people would want that automated. Changing the parity drive is one example. And probably the most common. It leaves you parityless.
January 20, 200917 yr I would also like to see dual parity, several operations in unraid leaves you parity-less when you do them. And for the record, dual-parity can be implemented without striping. I don't see how having dual parity helps with operations that leaves unRAID parity-less. Hot spare sounds good, right now I implement a warm spare... I.E. A drive sits in the array spun down. If I have a failure, I stop the array, re-assign the bad drive, and rebuild it onto the spare drive. Not sure how many people would want that automated. Changing the parity drive is one example. And probably the most common. It leaves you parityless. I do not agree with that statement as in effect, you have a complete copy of your parity drive (the one you just removed is valid as long as you do not write to the array) When you are changing the parity drive you still have the old parity drive. As long as you are not writing to the array at the same time you will be fine. If you save a copy of the config folder after you stop the array with the old parity drive, then power down, replace the drive, and power up with the new to build it you can at any time power down, put the old config folder back, re-install/assign the old parity drive and re-start. The array will not even know you had swapped out the old drive. (the config folder has the disk.cfg and super.dat files that together define your array and array state) In my opinion, the "replacement" of any drive with another is probably one of the safer operations you can perform, as you always have the old drive. Joe L.
January 20, 200917 yr If you save a copy of the config folder after you stop the array with the old parity drive, then power down, replace the drive, and power up with the new to build it you can at any time power down, put the old config folder back, re-install/assign the old parity drive and re-start. The array will not even know you had swapped out the old drive I believe the mount operation alone causes a write to the filesystem's superblock.(at least it does with other file systems).
Archived
This topic is now archived and is closed to further replies.