April 25, 201412 yr *** Contest is over, but feel free to take the quiz. Complete answers and explanations provided in the second post. *** Welcome one and all. Take the unRAID quiz below. Post your answers. Only five questions. Read the instructions for each question carefully. Some you have to answer all that apply, others you have to answer only one. PLEASE no dialog in this thread. Just your answers, e.g, 1. a, b, c, d, e 2. a, b, c, d, e 3. a, b, c, d, e 4. a 5. a First one right wins. That and $5.00 will get you a cup of coffee. I will give it a little time for people to try, and then post the winner (if any) and answers / explanations in the post below. Probably too easy. I try to think of some trickier ones for next time. 1. The following are benefits of a protected unRAID array over RAID-5 except (all that apply): a. Lower risk of total data loss b. Ability to recover from a single drive failure (assuming no drive fails during the rebuild) c. Ability to more easily grow the array d. Protects the overall integrity of your array better e. Slower writes 2. Which of the following are true about the unRAID parity disk (all that apply): a. unRAID requires a parity disk to establish an array b. the parity disk alone enables you to reconstruct one failed disk c. If you buy two drives of a newer (larger) size, and one has an HPA, it is better to not use it as the parity disk. d. a faster parity disk will result in faster performance in accessing data on the array e. it is a good idea to routinely back up your parity drive along with your data for extra protection 3. The following are true concerning the use of preclear (all that apply): a. Enables you to determine that a disk is perfect before adding it to your array b. Sets the preclear signature which speeds up rebuilding a failed disk c. Is much faster than using the unRAID preclear method way of adding a disk to an array d. Is of no value when introducing a new parity disk e. Was written primarily by Joe L. 4. I was moving a bunch of files from my computer to my protected array. The move completed successfully but in looking at the unRAID GUI, the disk I was moving the data to now has a red-ball. I shutdown and turned off my server and checked the cabling (learned that on the wiki!) and found that the data cable to that drive seemed to have wiggled loose. I replaced it with a locking cable and rebooted, but the disk is still red-balled. I am super freaked out. I think I have just lost a ton of data that I have not backed up. What should I do next (choose the ONE best answer from those listed)? a. Ask for advice on the forums. No question is too hard or too simple to ask on the forums. b. Run a parity check. c. Go buy a new disk and RMA the old one. Rebuild onto the new disk. Use a different port and another new cable for added security. Since I need access to the data quickly, I should buy a disk locally. d. Shut down and remove the drive from my server and put it in my workstation. Run the manufacturer diagnostics on the drive. Return it into the unRAID server and boot. Only if the red ball continues, do one of the other actions listed here. e. Form a new configuration from the array disks. Rebuild parity. (Or use the “trust parity”) procedure. 5. Three months ago I built my headless server. It has been running great ever since. Continuously on, I've done everything - precleared and added all my disks, rebuilt a disk so I'd know how, added packages, parity checks - I thought unRAID worked great. But today we had a power outage and the server crashed (my UPS is on order now!!) Upon rebooting every disk in the server is now showing unformatted. The parity check ran and produced 8 parity errors (almost immediately). That must explain the unformatting. I have a near full data backup of course, so this is not the end of the world. What should I do? a. Stop the array and start the array in maintenance mode. This will prevent all of the add on packages from loading. The addon packages may be causing the disks to not mount. If the unformatted goes away, you’ll have to research which package may be causing the problem. b. Suspect the USB disk is going bad. Compare the bzroot, bzimage files on the flash to copies directly from the distribution .zip file. If you have a backup, also compare the *.cfg files and super.dat. If you find differences, you need to get a new USB. Only if they compare fine, ask the forums for advice. Otherwise, get a new USB stick and ask Tom about activating the new key. When you get it, restore from your backup (if you have it) or build a new image. Toss the worn out USB stick. c. Edit my syslinux.cfg file on my flash drive. d. THIS is why I keep a backup. I should hit the format button, let the drives format. Then copy the data from the backup to the main array. e. Check the instructions for running reiserfsck with the rebuild tree. It should be able to restore the format to the disks and minimize data loss.
April 25, 201412 yr Author No winner. But some very close calls. Here are the answers with explanations: Thanks to all that tried. And those just reading, hope this helps you learn more about unRAID! 1. The following are benefits of a protected unRAID array over RAID-5 except (all that apply): a. Lower risk of total data loss Correct b. Ability to recover from a single drive failure (assuming no drive fails during the rebuild) Nope - applies equally to unRAID and RAID-5. c. Ability to more easily grow the array Correct d. Protects the overall integrity of your array better Nope - RAID-5 actually does a better job of maintaining the array integrity than unRAID. RAID-5 would fail the array rather than allow an integrity problem. Which would you rather, allow integrity issue in rare circumstance, or lose every bit of data in the entire array? With RAID-5 it all or nothing. unRAID allows in between. e. Slower writes True, but not a benefit 2. Which of the following are true about the unRAID parity disk (all that apply): a. unRAID requires a parity disk to establish an array Not required. You can run an unprotected array if you want to. b. the parity disk alone enables you to reconstruct one failed disk Not true. The parity disk can only reconstruct a failed disk in the presence of all other disks being operational, and in the array. c. If you buy two drives of a newer (larger) size, and one has an HPA, it is better to not use it as the parity disk. True. A drive with an HPA is usually a tiny bit smaller than full capacity, and although it doesn't matter much for data disks, is a big problem for parity. Because parity has to be the biggest, and being smaller by even a tiny amount would make you have to change your parity drive to install a full size data disk. It is interesting to note that drive manufacturers, since about the 200G timeframe, have standardized on very specfic drive sizes. So a Seagate, a WD, and a HGST 4T drive would all be exactly the same size. d. a faster parity disk will result in faster performance in accessing data on the array Not true. Faster parity would speed up only writes, and even then, only if the data drive were faster as well (or if you were doing multiple writes to the array at the same time) e. it is a good idea to routinely back up your parity drive along with your data for extra protection Not true. No value unless you are taking image copies of each and every drive which is not the way you'd keep backups. 3. The following are true concerning the use of preclear (all that apply): a. Enables you to determine that a disk is perfect before adding it to your array Nope. Preclear gives it a workout, but does not ensure it is perfect. b. Sets the preclear signature which speeds up rebuilding a failed disk Nope. It does set the preclear signature, but it is of no value in rebuilding a failed disk. But it is still a good idea to preclear it, because it is a pretty good test of the drive. c. Is much faster than using the unRAID preclear method way of adding a disk to an array Nope. Preclear runs a preread and post read in addition to the zeroing step. If you ran just the zeroing it would be similar speed as unRAID adding it. The advantage of preclearing is that it can occur while the array is up and active. If you let unRAID clear it, the array is offline the whole time. d. Is of no value when introducing a new parity disk Nope. Preclear is useful for checking a new parity drive for errors. Its preclear signature is not useful, but the testing is. e. Was written primarily by Joe L. True. And the community is eternally grateful! 4. I was moving a bunch of files from my computer to my protected array. The move completed successfully but in looking at the unRAID GUI, the disk I was moving the data to now has a red-ball. I shutdown and turned off my server and checked the cabling (learned that on the wiki!) and found that the data cable to that drive seemed to have wiggled loose. I replaced it with a locking cable and rebooted, but the disk is still red-balled. I am super freaked out. I think I have just lost a ton of data that I have not backed up. What should I do next (choose the ONE best answer from those listed)? a. Ask for advice on the forums. No question is too hard or too simple to ask on the forums. True. What he would be told is to rebuild on top of the existing disk (or onto another spare disk). The disk is not bad. Fixing a cabling issue does not remedy a red-ball. It remedies the reason it red balled. But it will remain in the red ball state until the disk is rebuilt or a trust parity new configuration is done. See answer (e) for why the trust parity procedure is a bad idea here. b. Run a parity check. Nope. A parity check would not even run on an array with a red ball. c. Go buy a new disk and RMA the old one. Rebuild onto the new disk. Use a different port and another new cable for added security. Since I need access to the data quickly, I should buy a disk locally. This would work, and have to give some credit to anyone that picked it. But it involves RMAing a perfectly good drive and wasting money of a full price retail disk. Not the best option. d. Shut down and remove the drive from my server and put it in my workstation. Run the manufacturer diagnostics on the drive. Return it into the unRAID server and boot. Only if the red ball continues, do one of the other actions listed here. Nope. Since the user found a cabling problem, there is no reason to believe the drive is bad. At the most you'd run a smart report. And even if the disk was bad and the diagnostics fixed something, it would never cure the red ball. e. Form a new configuration from the array disks. Rebuild parity. (Or use the “trust parity”) procedure. Nope. The disk failed in the middle of having a bunch of data moved to it. (If you did the trust parity and ran a parity check, you'd have a ton of parity errors). Afterward you'd have lost all of the files that moved after the drive was kicked from the array. Since the files were moved from the workstation and not just copied, you'd have lost those files. 5. Three months ago I built my headless server. It has been running great ever since. Continuously on, I've done everything - precleared and added all my disks, rebuilt a disk so I'd know how, added packages, parity checks - I thought unRAID worked great. But today we had a power outage and the server crashed (my UPS is on order now!!) Upon rebooting every disk in the server is now showing unformatted. The parity check ran and produced 8 parity errors (almost immediately). That must explain the unformatting. I have a near full data backup of course, so this is not the end of the world. What should I do? Brief comment on the question. The 8 parity errors had nothing to do with the unformatting. They were a byproduct of the dirty shutdown. a. Stop the array and start the array in maintenance mode. This will prevent all of the add on packages from loading. The addon packages may be causing the disks to not mount. If the unformatted goes away, you’ll have to research which package may be causing the problem. Nope. But oh so close. It is not maintenance mode but safe mode that does this! You cannot stop the array and enable safe mode, it requires a reboot. Maintenance mode simply starts the array but does not mount the disks. See the correct answer for more details. b. Suspect the USB disk is going bad. Compare the bzroot, bzimage files on the flash to copies directly from the distribution .zip file. If you have a backup, also compare the *.cfg files and super.dat. If you find differences, you need to get a new USB. Only if they compare fine, ask the forums for advice. Otherwise, get a new USB stick and ask Tom about activating the new key. When you get it, restore from your backup (if you have it) or build a new image. Toss the worn out USB stick. Nope. So many issues with the solution its hard to tell where to start. USB drives don't die this way. Comparing bzroot and bzimage does no harm, nor does comparing the .cfg files. But comparing the super.dat file will always differ, as it is updated with every startup and shutdown of the array. And rebuilding a USB from a backup is a recipe for disaster if there have been any disk changes, especially installing a new parity and using the old parity as a data disk. This answer couldn't be more wrong even if the USB had failed! c. Edit my syslinux.cfg file on my flash drive. Ding ding ding. If you have a headless server, the only way to enable safe mode is to edit this file and change the default boot option to safe mode. See answser (a) for what safe mode does. Thanks to dgaschk for teaching this old dog a new trick (See HERE) d. THIS is why I keep a backup. I should hit the format button, let the drives format. Then copy the data from the backup to the main array. Nope. Hitting format would not solve the problem. The disks still would not mount. But you certainally would have formatted every disk in your array. Once you figured that out the problem got them mounted you'd be spending days (at least) restoring your array from the backups. e. Check the instructions for running reiserfsck with the rebuild tree. It should be able to restore the format to the disks and minimize data loss. Nope. Reserfsck is not needed if drives as the disks are not damaged. You can always run the "fdisk -l /dev/sdX" command to check if there is a Linux partition on the drive. If IT doesn't show one and the drive is showing unformatted, the Linux partition is really gone. At that time this option may be in order. Hope this was helpful. unRAID is a powerful platform that gives you the tools to protect your data. But if you don't know how to use the tools properly, you can easily make a nonproblem into a real problem, and a recoverable situation into a lost cause. Knowing the information above, not just the right answers, but why they are right and why the wrong ones are wrong, will help you to understand what's happening so you can problem solve your way through your issues like a pro. Stay tuned for another quiz and opportunity to win that elusive cup of coffee!
April 25, 201412 yr Welcome one and all. Take the unRAID quiz below. Post your answers. 1. a c 2. c 3. e 4. a 5. a I drink my coffee without milk or sugar. Joe L.
April 26, 201412 yr I expected to have a problem with the wording of the first question, because of the last word "except". That to me means which of the choices are not an advantage of unRAID. Clearly slower writes are not an advantage. I still missed some of the other choices, though. On number 4, asking for advise would always be the correct answer in any situation where you are uncertain, so even if there were another good answer asking would be right and probably a good idea just to get a second opinion. On number 5 I might have come up with your solution if my server were truly headless, but I can easily connect it to the 2nd input on my PCs monitor and have a spare keyboard so I can boot into safe mode if I want. Another possibility would be to remove addons which is what we all did before safe mode was implemented.
April 26, 201412 yr Nice... d. Protects the overall integrity of your array better Nope - RAID-5 actually does a better job of maintaining the array integrity than unRAID. RAID-5 would fail the array rather than allow an integrity problem. Which would you rather, allow integrity issue in rare circumstance, or lose every bit of data in the entire array? With RAID-5 it all or nothing. unRAID allows in between. Correct answer is: unRAID and RAID-5 protects array "integrity" just the same. Though, what do you mean by "integrity"? c. If you buy two drives of a newer (larger) size, and one has an HPA, it is better to not use it as the parity disk. True. A drive with an HPA is usually a tiny bit smaller than full capacity, and although it doesn't matter much for data disks, is a big problem for parity. Because parity has to be the biggest, and being smaller by even a tiny amount would make you have to change your parity drive to install a full size data disk. It is interesting to note that drive manufacturers, since about the 200G timeframe, have standardized on very specfic drive sizes. So a Seagate, a WD, and a HGST 4T drive would all be exactly the same size. What drive manufacturers pre-configure an HPA these days? Probably zero. Could be an issue repurposing existing drives I suppose. [regarding preclear] e. Was written primarily by Joe L. True. And the community is eternally grateful! Mee too For question 4, add option: f) Replace drive with a different one of the same size and start a rebuild. This restores array integrity and buys time to run more thorough diags on the "bad" disk. For question 5, add option: f) Email [email protected] or [email protected] and ask wtf is wrong that all disks are showing unformatted. If this is truely the case then your power failure probably killed something like your PSU or some other key h/w component. Also if you are really running "headless" maybe you have IPMI capability on your motherboard - in which case you can modify the boot sequence from your PC.
April 27, 201412 yr What drive manufacturers pre-configure an HPA these days? Probably zero. There was some mention on this forum of an external drive liberated from its case to be used internally having HPA. I can't remember which manufacturer.
April 27, 201412 yr What drive manufacturers pre-configure an HPA these days? Probably zero. There was some mention on this forum of an external drive liberated from its case to be used internally having HPA. I can't remember which manufacturer. The drive's referred to above were removed from WD MyBook external drives. It was discovered during the discussions in this thread: http://lime-technology.com/forum/index.php?topic=32878.msg302208#msg302208 ... and there's a follow-up thread warning about this possibility here: http://lime-technology.com/forum/index.php?topic=32894.0 By the way, r.e. Question 2, I would say there was actually NO correct answer ... although I did select the answer bjp was looking for. But that answer implies there's a CHOICE ... i.e. "... it is better to not use it as the parity disk." In fact, there's NO CHOICE -- it's not "better" ... it's the only option.
April 27, 201412 yr Author Nice... Thanks!! Trying to keep the community on its toes. d. Protects the overall integrity of your array better Nope - RAID-5 actually does a better job of maintaining the array integrity than unRAID. RAID-5 would fail the array rather than allow an integrity problem. Which would you rather, allow integrity issue in rare circumstance, or lose every bit of data in the entire array? With RAID-5 it all or nothing. unRAID allows in between. Correct answer is: unRAID and RAID-5 protects array "integrity" just the same. Though, what do you mean by "integrity"? By integrity I mean not allowing any data corruption to exist. Keeping the data and the protection synchronized. Parity can get out of whack (very rare but technically possible) and not be detected until a parity check is performed or a rebuild is corrupted. RAID-5s striping would not allow the protection to be lost by its very nature. It is important that users understand that parity must be checked periodically to ensure the array maintains integrity. c. If you buy two drives of a newer (larger) size, and one has an HPA, it is better to not use it as the parity disk. True. A drive with an HPA is usually a tiny bit smaller than full capacity, and although it doesn't matter much for data disks, is a big problem for parity. Because parity has to be the biggest, and being smaller by even a tiny amount would make you have to change your parity drive to install a full size data disk. It is interesting to note that drive manufacturers, since about the 200G timeframe, have standardized on very specfic drive sizes. So a Seagate, a WD, and a HGST 4T drive would all be exactly the same size. What drive manufacturers pre-configure an HPA these days? Probably zero. Could be an issue repurposing existing drives I suppose. As noted this happened recently with a drive harvested from a USB enclosure. I acknowledge Gary's point that unRaid would force a user to use the larger (non HPA) drive for parity, but wanted users to know that HPA on a parity disk can cause issues later on. [regarding preclear] e. Was written primarily by Joe L. True. And the community is eternally grateful! Mee too For question 4, add option: f) Replace drive with a different one of the same size and start a rebuild. This restores array integrity and buys time to run more thorough diags on the "bad" disk. The drive red-balled due to cabling. I agree that rebuilding on the same (or better yet a different disk) is the best option. I intentionally left off the perfect answer to make the problem harder. A freaked out user that doesn't know what to do should ask on the forums. But I agree with you if there are reasons to suspect the disk really is bad, drive diagnostics are appropriate. The main point here is that fixing the cause of a red ball does not make the red ball go away For question 5, add option: f) Email [email protected] or [email protected] and ask wtf is wrong that all disks are showing unformatted. If this is truely the case then your power failure probably killed something like your PSU or some other key h/w component. Also if you are really running "headless" maybe you have IPMI capability on your motherboard - in which case you can modify the boot sequence from your PC. There is a new bug report on this one due to a package that removed mount points. See RobJ's explanation. I will add your suggestion to the answer.
April 27, 201412 yr By integrity I mean not allowing any data corruption to exist. Keeping the data and the protection synchronized. Parity can get out of whack (very rare but technically possible) and not be detected until a parity check is performed or a rebuild is corrupted. RAID-5s striping would not allow the protection to be lost by its very nature. It is important that users understand that parity must be checked periodically to ensure the array maintains integrity. I think what you are referring to is a RAID-5 "stripe-write" operation. In this case sure all the data for a stripe is "new" data and so the parity is directly calculated and written in parallel with all the data writes. But often as data is being written to a RAID-5 array, not all the data for a stripe is provided as "new" data. In this case some "old" data must be read in order to form "new" parity - this is known as a "reconstruct-write". In the degenerate case, known as a "small-write", the RAID-5 code must read/modify/write both the data disk and the parity disk just like unRAID. Turns out almost all writes to a RAID-5 array are indeed "small-writes" except when writing very large files. In all these write cases, great pains are taken to ensure array parity "integrity". Therefore in regards to "integrity", unRAID is equivalent to all the other RAID organizations; in fact, all the RAID organizations are equivalent to each other. How then does array parity get "out of sync"? Or stated another way, when someone runs a Parity Check operation, why does sometimes it report "sync errors"? There are only two possibilities: 1. You didn't let original parity sync operation complete. In this case all "stripes" beyond the point where parity sync was stopped may report "sync errors". 2. There was an unclean shutdown during a time when writes were in-progress on the array. For example, suppose we are writing a block of a file and the driver has reached the point where it has issued a write command to the target data disk and a write command to the parity disk. Now suppose the data disk write finishes but the parity disk write has not finished and at that instant a system reset occurs (or power loss or PSU failure or software bug, etc). The "stripe" is now in a state where, if we XOR all the data contents it will not match the parity disk contents for that stripe. We don't know which disk(s) have incorrect data, we just know the stripe as a whole has wrong parity. In such a case, when unRaid starts up again, it will immediately kick off a "correcting" parity check operation. When this operation reaches the stripe(s) with compromised "integrity" it will generate parity from the data disks of the stripe and write the parity disk. This will let us rebuild any disk that subsequently suffers a failure in that stripe. This same issue of dealing with compromised "integrity" exists with all RAID organizations, and different storage subsystems address it in varying ways. Ok, well there are some other ways "integrity" can be compromised: 3. "Silent" read error - this is a case where a disk read returned the wrong data but reported the read as 'successful'. Other possibility is a silent memory corruption, or data corruption on some path between the disk media and the CPU memory. Modern computer systems make this kind of problems extremely unlikely (but not impossible). 4. "Silent" write error - typically when data is written to a disk it is not checked to see if the data was really written to the media. To do so would be very expensive from a write-speed point of view because the subsystem would have to wait for the written sector(s) to rotate back under the read/write head and then do a read-verify. But the ATA (and SCSI) command set includes a "WRITE-VERIFY" command that does exactly that. Not many subsystems that I'm aware of routinely use it however.
April 27, 201412 yr Author There are, in fact, a few other ways ... 1 - A user takes a drive out of the array and writes silently writes to it. 2 - A bug exists in preclear (for example) where a disk is not zeroed correctly (no bug like this exists but just an example of such an opportunity) In general, users have much easier access to unRAID devices and configurations than to RAID devices and configurations, and generally have the tools to shoot themselves in the foot. RAID-5 (at least what I've used) is hidden behind a hardware interface and make manipulating the underlying disks harder and, depending on the implementation, subject to internal integrity checks that are happening on the array that will find integrity issues and kick a disk from the array or maybe knock the entire array offline. If parity gets mucked up in unRAID, there are no symptoms unless you do a parity check. And if you don't, and a disk fails, your rebuild will be imperfect. Not trying to make a bigger deal of it than it is, but I think it is important to understand. Here's an example that could happen without a user understanding. Say a user backs up their flash drive (say they are smart enough to do it while the array if offline). They later add a precleared disk to their array, and starts loading data to it. All good. Then they have an issue with a plugin and decide to restore their flash backup, which works fine. The array says it is a valid configuration and comes online. They don't realize that their newest disk is missing. No parity check is performed. Then a drive really fails, and they go to rebuild it.
April 27, 201412 yr Three comments on the discussion above r.e. RAID-5 vs UnRAID: (1) Mathematically, the protection provide by the two is IDENTICAL. Virtually all of the potential data loss events can occur in either case. The vast majority of them can be avoided by simply using a UPS (which I consider mandatory for any PC, ESPECIALLY a server). But in any event, the potential corruption isn't statistically any different ... it simply manifests itself in slightly different ways. (2) r.e. the comments about booting with the wrong USB flash drive -- ANY system can be royally "hosed" if the user does dumb (perhaps "ill informed" is a better descriptor) things. This has nothing to do with UnRAID vs. RAID-5. Taking a drive out of ANY RAID system and writing to it independently will decidedly mess things up !! In fact, I think the emphasis many folks have on always doing non-correcting checks, and then making various guesses about why the sync errors may not be real, probably increase the odds something incorrect might be done. Except for a non-correcting check immediately after a rebuild (as a test that the rebuild went okay), I don't EVER recommend running non-correcting checks. (3) Many years ago when I was writing driver-level code for embedded OS's, I always did write verifies in the disk I/O, despite the performance impact. I tend to be a paranoid guy when it comes to protecting against data loss ALL of my writes to UnRAID are done with TeraCopy with the validation option-- so everything is read after the writes and at least CRC validated (which isn't a true compare, but statistically is good enough). If UnRAID had an option to use the WRITE-VERIFY ATA command with all writes, I'd certainly check that box, despite the performance hit. This little "quiz" certainly generated some interesting thoughts
April 28, 201412 yr Author Three comments on the discussion above r.e. RAID-5 vs UnRAID: (1) Mathematically, the protection provide by the two is IDENTICAL. Virtually all of the potential data loss events can occur in either case. The vast majority of them can be avoided by simply using a UPS (which I consider mandatory for any PC, ESPECIALLY a server). But in any event, the potential corruption isn't statistically any different ... it simply manifests itself in slightly different ways. Agreed (2) r.e. the comments about booting with the wrong USB flash drive -- ANY system can be royally "hosed" if the user does dumb (perhaps "ill informed" is a better descriptor) things. This is my point. I'd say ignorant is a better word. Users are ignorant of how unRAID works in many respects, and that ignorance makes them apt to make mistakes. For example, believing that when unRAID says that the configuration is valid, they read more into that then is meant. It does not mean that parity is correct. It only means that the disk configuration matches what unRAID has on file on the memory stick. This has nothing to do with UnRAID vs. RAID-5. Taking a drive out of ANY RAID system and writing to it independently will decidedly mess things up !! It's all about packaging. RAID-5, all packaged in the hardware, makes it harder to screw up. The configuration is not something you can backup and overwrite. You cannot access drives by their /dev/sdX names. To the user a RAID-5 array is just a black box. Now I don't want a black box. I like to be able to tinker. I would be very disappointed to have the whole array suddenly go tits up with no explanation and minimal if any means of recovery. I am very happy with the way unRAID works (of course I would like a few tweaks). But I DO believe that using unRAID requires a more knowledgeable user that using RAID-5. So in my mind, unRAID and RAID-5 are more different even though they use the same algorithms. In fact, I think the emphasis many folks have on always doing non-correcting checks, and then making various guesses about why the sync errors may not be real, probably increase the odds something incorrect might be done. Except for a non-correcting check immediately after a rebuild (as a test that the rebuild went okay), I don't EVER recommend running non-correcting checks. You know how I feel about this. The correcting parity check is the right action some huge percentage of the time But when a user makes a mistake and runs (or unRAID runs it for him) a correcting check that suddenly starts updating parity like a madman - that is a bad thing. There are several solutions. The one I like best is having unRAID remember sync locations and let you apply them later. Another idea is to have unRAID do a short uncorrecting check on a few gigs early, middle, and near end of the drives. If they are clean the chances that a parity check surprise are much much less. (3) Many years ago when I was writing driver-level code for embedded OS's, I always did write verifies in the disk I/O, despite the performance impact. I tend to be a paranoid guy when it comes to protecting against data loss ALL of my writes to UnRAID are done with TeraCopy with the validation option-- so everything is read after the writes and at least CRC validated (which isn't a true compare, but statistically is good enough). If UnRAID had an option to use the WRITE-VERIFY ATA command with all writes, I'd certainly check that box, despite the performance hit. I'll live on the edge with the infinitesimal risk. This little "quiz" certainly generated some interesting thoughts And I hope helped educate some of the spectators.
April 28, 201412 yr And I hope helped educate some of the spectators. Yes! Thank you for your efforts here. A very good read. Much of this could form the basis of a stickied FAQ. (But please don't ask me - life just too busy right now - same reason I did not do the quiz in the first place.) And since it has been debated above... The reason that I prefer always to run non-correcting parity checks is not related to the probability of a particular type of error. It is simply that if there is an error reported, I then have time to think before any next step, and ask questions if necessary. In my case, having an pretty good understanding of the workings of parity schemes, hard drives at a pretty low-level of detail, etc, it is simply the fact that I have that opportunity which informs my choice. I may very well then choose to run a correcting parity check, but the decision is mine to take. I accept, however, that for many users, for the very clear reasons outlined previously by Tom and Gary, an automatic correcting check is generally the best option.
April 28, 201412 yr Author And I hope helped educate some of the spectators. Yes! Thank you for your efforts here. A very good read. Much of this could form the basis of a stickied FAQ. (But please don't ask me - life just too busy right now - same reason I did not do the quiz in the first place.) And since it has been debated above... The reason that I prefer always to run non-correcting parity checks is not related to the probability of a particular type of error. It is simply that if there is an error reported, I then have time to think before any next step, and ask questions if necessary. In my case, having an pretty good understanding of the workings of parity schemes, hard drives at a pretty low-level of detail, etc, it is simply the fact that I have that opportunity which informs my choice. I may very well then choose to run a correcting parity check, but the decision is mine to take. I accept, however, that for many users, for the very clear reasons outlined previously by Tom and Gary, an automatic correcting check is generally the best option. Thanks!
Archived
This topic is now archived and is closed to further replies.