July 2, 200818 yr I have a suggestion for fixing this that would have wider utility. It would be nice to have a button that works like "Restore" with a twist. Maybe called "Trust Parity". Like the Restore button, the "Trust Parity" button would set the configuration based on the currently assigned drives. But instead of assuming parity was bad and starting a parity rebuild, it would assume the parity was good and start a parity check. In this situation, you'd be able to set your devices, press the "Trust Parity" button, and immediately have a protected array again. It would merely act as if the parity check button had been pressed. The difference is that with VALID PARITY, if a drive happened to fail in the middle of the parity check - unRAID would be able to rebuild it. If a bad sector were detected, unRAID would be able to correct it. With the Restore button, both of these would result in data loss. I could see utility of this feature if you had a drive get removed from the array (for example, if a drive cable came loose). You could then just plug it back in and then push "Trust Parity". The drive would instantly become a part of the protected array again, and the parity check would just verify that all was well. If a few sectors were different - no big deal. The parity check would correct the parity data. If you pressed "Trust Parity" and the parity drive was not in sync with the data disks - no real harm. The parity check would find and correct any parity errors - and at the end all would be well. The end result would be the same as if the "Restore" button had been pressed. Thoughts?
July 2, 200818 yr I have a suggestion for fixing this that would have wider utility. It would be nice to have a button that works like "Restore" with a twist. Maybe called "Trust Parity". Like the Restore button, the "Trust Parity" button would set the configuration based on the currently assigned drives. But instead of assuming parity was bad and starting a parity rebuild, it would assume the parity was good and start a parity check. Thoughts? Nice Idea, but Way too dangerous... Tom has many "appliance" users, who would press that button because they just installed a NEW parity drive and they now "Trust" it. Any feature even remotely similar should be kept hidden from most users. With that thought in mind... all that is really needed is a simple way to calculate the checksum for the superblock (system.dat) file. We could then edit the model/serial numbers using already available utilities, set the "clean" bit in the super.dat file, calculate the appropriate checksum, and start the array. What is missing is the checksum. Yes, it will be an exercise for many, but it will be rarely used, and anybody using it would hopefully know more of what they are doing. Joe L.
July 2, 200818 yr Joe, Problem is in this code from import_device() in md.c: data = buf+8; count = 24; /* skip the "ATA " string prepended by libata */ data += 8; count -= 8; memcpy( rdev->model, data, count); This copies the 16 'model' bytes from the SCSI Inquiry response. Here's the problem: if you look at md.c in the 4.3.2 release, it no longer directly sends scsi command to scsi devices; instead it just uses the HDIO_GET_IDENTITY ioctl call. This call originally didn't work with SATA drives because libata (linux sata layer) didn't support it (it also didn't support some other ones related to setting spin-down and reading SMART data - you might recall some of the early unRAID OS releases for SATA had some quirks in this area). However, libata is now pretty much fully functional, so HDIO_GET_IDENTITY (and others) will now "do the right thing". This is good because when you have more than 16 SATA hard drives, this test: if ( MAJOR(dev) == 8 ) { no longer always works (additional majors get assigned as you add more disks). So the code was changed to strictly use HDIO_GET_IDENTITY. Simply truncating the model string to 16 chars won't work. I think the best solution is just to use your favorite button: Restore or perhaps the "trust" suggestion from bjp999. I think I'll sleep on it.
July 2, 200818 yr Author Info attached as requested. My syslogs are in my previous posts in this thread.
July 2, 200818 yr Joe, Problem is in this code from import_device.c <snip> Simply truncating the model string to 16 chars won't work. I did not truncate the model strings themselves, just the temporary str1 and str2 use for the model compare. It would be more than sufficient for that test. If the model number comparison is being done in other code, or in in emhttp, the truncate of the strings used for the comparison, as I indicated (at 16 chars, not 20) would not do all that is needed. Get a good night's sleep. Joe L. I tossed and turned all night, after I realized I had actually advised people to use the evil "Restore" button when they were not removing a drive from the array
July 2, 200818 yr Restore or perhaps the "trust" suggestion from bjp999. I think I'll sleep on it. Re-Store or "Trust".. Are these separate items (just trying to be clear). I read the suggestion on Trust, but I thought that was to "assume" and "trust" parity as valid. and "re-store" or "set config" is to update the superblock.dat as is, and recompute parity.
July 2, 200818 yr Joe L. I tossed and turned all night, after I realized I had actually advised people.... How flattering... you think of us all night in your dreamtime !!! Now that's dedication !!! Eh, don't feel bad.. I write code in my dreams. I find myself designing a new lighttpd/control plugin interface in my dreams lately. Theta State is a great place for inspiration.
July 2, 200818 yr Re-Store or "Trust".. Are these separate items (just trying to be clear). I read the suggestion on Trust, but I thought that was to "assume" and "trust" parity as valid. and "re-store" or "set config" is to update the superblock.dat as is, and recompute parity. Tom could package it in different ways, be it its own button, a checkbox to be used in conjunction with the existing "Restore" button, or something else - it's up to him.
July 2, 200818 yr Here's the workaround. Do this only if you know the configuration was completely valid before upgraded, ie, no disabled or missing disks, parity is valid. 1. Boot server normally & observe array not started due to hard drive model being off by at most 4 characters (same s/n though). 2. Click Restore (after first checking "I'm sure I want to do this" box). This will result in all disk status symbols being 'blue'. The server state should be, "Stopped. Initial Configuration". 3. From the console or telnet window, type this command: mdcmd set invalidslot 99 The output of this command should be this: cmdOper=set cmdResult=ok 4. Now click Start. All the disk status indicators should turn Green; the system state should be Started; and, there should be a parity-check in progress. You can let the parity-check complete or cancel it. Edit: struck out phase, "by at most 4 characters" (not true).
July 2, 200818 yr One of my disks is off by 5 characters: ata-WDC_WD7500AAKS-00RBA0_WD-WCAPT0194953 ata-WDC_WD7500AAKS-0_WD-WCAPT0194953 Is it okay to use the same procedure?
July 2, 200818 yr One of my disks is off by 5 characters: ata-WDC_WD7500AAKS-00RBA0_WD-WCAPT0194953 ata-WDC_WD7500AAKS-0_WD-WCAPT0194953 Is it okay to use the same procedure? Can you please post your syslog and also the output of this command: v /dev/disk/by-id Thanks!
July 2, 200818 yr One of my disks is off by 5 characters: ata-WDC_WD7500AAKS-00RBA0_WD-WCAPT0194953 ata-WDC_WD7500AAKS-0_WD-WCAPT0194953 Is it okay to use the same procedure? Can you please post your syslog and also the output of this command: v /dev/disk/by-id Thanks! Here they are. Thank you!
July 3, 200818 yr Here's the workaround. Do this only if you know the configuration was completely valid before upgraded, ie, no disabled or missing disks, parity is valid. 1. Boot server normally & observe array not started due to hard drive model being off by at most 4 characters (same s/n though). 2. Click Restore (after first checking "I'm sure I want to do this" box). This will result in all disk status symbols being 'blue'. The server state should be, "Stopped. Initial Configuration". 3. From the console or telnet window, type this command: mdcmd set invalidslot 99 The output of this command should be this: cmdOper=set cmdResult=ok 4. Now click Start. All the disk status indicators should turn Green; the system state should be Started; and, there should be a parity-check in progress. You can let the parity-check complete or cancel it. Sounds a bit like an undocumented "trust parity" feature. Excellent!
July 3, 200818 yr Sounds a bit like an undocumented "trust parity" feature. Excellent! Actually, its existence was documented, and the code for it commented. What was missing was how to use it after pressing "Restore" but before starting the array. I made mention of it about a month ago in this thread: http://lime-technology.com/forum/index.php?topic=2101.msg15414#msg15414 I like how a new user of unRAID is highly unlikely to accidentally invoke it under the wrong set of conditions. Thanks Tom. Joe L.
July 3, 200818 yr Author Here's the workaround. Do this only if you know the configuration was completely valid before upgraded, ie, no disabled or missing disks, parity is valid. 1. Boot server normally & observe array not started due to hard drive model being off by at most 4 characters (same s/n though). 2. Click Restore (after first checking "I'm sure I want to do this" box). This will result in all disk status symbols being 'blue'. The server state should be, "Stopped. Initial Configuration". 3. From the console or telnet window, type this command: mdcmd set invalidslot 99 The output of this command should be this: cmdOper=set cmdResult=ok 4. Now click Start. All the disk status indicators should turn Green; the system state should be Started; and, there should be a parity-check in progress. You can let the parity-check complete or cancel it. Works for me. I'm letting the parity-check run just because.
July 3, 200818 yr Here's the workaround. Do this only if you know the configuration was completely valid before upgraded, ie, no disabled or missing disks, parity is valid. 1. Boot server normally & observe array not started due to hard drive model being off by at most 4 characters (same s/n though). 2. Click Restore (after first checking "I'm sure I want to do this" box). This will result in all disk status symbols being 'blue'. The server state should be, "Stopped. Initial Configuration". 3. From the console or telnet window, type this command: mdcmd set invalidslot 99 The output of this command should be this: cmdOper=set cmdResult=ok 4. Now click Start. All the disk status indicators should turn Green; the system state should be Started; and, there should be a parity-check in progress. You can let the parity-check complete or cancel it. Works for me. I'm letting the parity-check run just because. Great news... Can you attach one more syslog? So we can see the difference now. It is very rare to see a "Restore" log, and certainly not one where the superblock is fixed like this. Joe L. PS. No need to cancel the parity check, or wait for the parity check to finish before capturing the log.
July 3, 200818 yr Sure, give me about 420 minutes I probably did not type what I wanted to say correctly. A syslog, now, before the parity check is completed, is perfectly fine.
July 3, 200818 yr ...so in the end of all this... do we wait for a 4.3.3 or not? I think this IS the fix for this issue. Unless I have missed something, I don't think that any 4.3.2 issues are really bugs, and have not heard Tom mention a 4.3.3. I am looking forward to 4.4 (or maybe 5.0) with full PB&J making capability.
July 3, 200818 yr ...so in the end of all this... do we wait for a 4.3.3 or not? If you have to ask, then you should probably wait.
July 3, 200818 yr Sure, give me about 420 minutes I probably did not type what I wanted to say correctly. A syslog, now, before the parity check is completed, is perfectly fine. Here's one. Finished the parity check some time last night.
July 3, 200818 yr Author Sure, give me about 420 minutes I probably did not type what I wanted to say correctly. A syslog, now, before the parity check is completed, is perfectly fine. Sorry, I miss read your post. The attached syslog is UnRAID 4.3.2 w/"missing" drives after using the RESTORE button and the "mdcmd set invalidslot 99" command
July 3, 200818 yr Author ...so in the end of all this... do we wait for a 4.3.3 or not? Do to the nature of the issue as I understand it, I assume skipping this version and upgrading to some subsequent version may produce the same result as 4.3.1 to 4.3.2. Once you've performed the steps outlined by Limetech in post #33 you should be set for all subsequent versions. Someone a little more knowledgeable please correct me if I'm wrong.
Archived
This topic is now archived and is closed to further replies.