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.

 

Unless Tom does something different - which he has not said he would do - you are 100% correct.  Tom has implemented a fundamentally different way of obtaining the drive string, and will likely stay that way in future versions, at least for the forseeable future.

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. 

 

Semantic argument aside about what it means for a feature to be documented, I am pretty excited about this!  TO ME it is the best "feature" in 4.3.  (The cache disk feature is also great but I have been using something similar that Joe L. helped me setup in 4.2, and never have moved over to the "real" cache feature.)  I think I will finally upgrade my OS from beta 3.  I 100% agree with Joe L. that this is a powerful command and should be used with caution.

 

This feature makes a significant number of problem scenarios much easier to recover from, including a disconnected drive scenario.  Also, if you want to remove a disk from the array, and are willing to write binary zeros to the drive before removing it, I think you could use this feature to avoid risks associated with a lengthy rebuild parity cycle.  (I will do some experimenting, prove it can be done, and write a post documenting the procedure soon.)

 

Tom, thanks for communicating how to do this.  I hope you don't view this as letting the hens out of the hen house.  I am sure the community will be very responsible about communicating its proper use, as we have with other uses of the dreaded restore button. 

 

Thanks again!

 

Brian

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.

Fascinating reading...  (for geeks like me)

 

From what I can see, the "restore" button removes the system.dat file that contains the superblock for the "md" arrray, and that forces the "md" kernel driver to build a new one using the information from the assigned disks.  

 

For this specific issue, the name mismatch goes away, since the model/serial numbers will be exactly those supplied from the disks.

 

Thank you.

 

Joe L.

...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.

 

Exactly.

 

Basically, if you have an SATA drive with a longer than 20 character model number on an earlier release than 4.3, its model number is being truncated. 

 

If a person upgrades from pre-4.3 to 4.3.2 onward, this exact same issue can occur. It will affect a minority of users, only if they have similar model/series drives with the longer model numbers.  Tom probably needs a special note in the release notes going forward to re-assure people it might occur if they have WD drives and not to panic.  (so far, they are the only drive we know that have the longer model numbers)

 

Joe L.

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?

 

Ok, this had me stumped for a long time... The above model number:

WDC_WD7500AAKS-00RBA0

is clearly longer than 20 characters (it's 21).  According to ATA spec, I thought the longest "model" field of IDENTIFY DEVICE data was 20 characters, so I had to figure out where that extra '0' was coming from.  Turns out the "model" field is actually 20 16-bit words - doh!  Oh well, learned alot more about the libata code... 

 

So the "workaround" posted earlier is the way to go to fix this problem & I'll post a version of it in the Announcement forum as well.  This problem didn't show up in testing because we don't have any drives with model numbers longer than 16 characters.  Thanks again to the Community for helping to solve this problem.

 

The 'mdcmd set invalidslot <n>' command, as others have pointed out, may be used to alter the behavior of the unRAID driver when Starting a "new" array.  It defines which slot should start out as having "invalid data".  Normally this is always slot 0 (parity).  But if you have lost the super.dat file, and you know that parity is valid, but some other slot has an invalid or missing disk, you can use this command to indicate this.  By using a value (like 99) which is larger than the highest possible slot number, it has the effect of having all the slots come up "valid".

This feature makes a significant number of problem scenarios much easier to recover from, including a disconnected drive scenario.

That's correct, and it was added to recover from exactly that.  We have used this a couple of times to solve problems people have reported via email.  Main reason I haven't talked about it on the forums is because if used incorrectly then someone could really mess up their data which would create an even worse support issue.

 

  Also, if you want to remove a disk from the array, and are willing to write binary zeros to the drive before removing it, I think you could use this feature to avoid risks associated with a lengthy rebuild parity cycle.  (I will do some experimenting, prove it can be done, and write a post documenting the procedure soon.)

Yes this should work.  Just make sure all the array devices are un-mounted before trying this.  That is, un-mount all the md-devices, write zeros to the one you plan on removing.  When done, power off, remove disk, power on, click Restore, 'mdcmd set invalidslot 99', then Start should work - but let the parity check complete just in case 

 

Tom, thanks for communicating how to do this.  I hope you don't view this as letting the hens out of the hen house.  I am sure the community will be very responsible about communicating its proper use, as we have with other uses of the dreaded restore button. 

 

Thanks again!

 

Brian

 

Yes, a great community here!

From what I can see, the "restore" button removes the system.dat file that contains the superblock for the "md" arrray, and that forces the "md" kernel driver to build a new one using the information from the assigned disks. 

Exactly right, though it actually renames it from super.dat to super.old.

 

For this specific issue, the name mismatch goes away, since the model/serial numbers will be exactly those supplied from the disks.

 

So we don't have to change the name of that button after all, right?

So we don't have to change the name of that button after all, right?

 

I would still suggest renaming Restore.

Restore implies taking an old version of something and putting currently in place.

If I am getting this correctly the button actually renames super.dat to super.old thereby invalidating parity and initializing super.dat

 

Therefore I would still suggest a new name.

I liked Set Device Configuration (even though it's large).  "Initialize" could be a short name. ("Force") could be another.

 

This feature makes a significant number of problem scenarios much easier to recover from, including a disconnected drive scenario.

That's correct, and it was added to recover from exactly that.  We have used this a couple of times to solve problems people have reported via email.  Main reason I haven't talked about it on the forums is because if used incorrectly then someone could really mess up their data which would create an even worse support issue.

 

  Also, if you want to remove a disk from the array, and are willing to write binary zeros to the drive before removing it, I think you could use this feature to avoid risks associated with a lengthy rebuild parity cycle.  (I will do some experimenting, prove it can be done, and write a post documenting the procedure soon.)

Yes this should work.  Just make sure all the array devices are un-mounted before trying this.  That is, un-mount all the md-devices, write zeros to the one you plan on removing.  When done, power off, remove disk, power on, click Restore, 'mdcmd set invalidslot 99', then Start should work - but let the parity check complete just in case 

 

Tom, thanks for communicating how to do this.  I hope you don't view this as letting the hens out of the hen house.  I am sure the community will be very responsible about communicating its proper use, as we have with other uses of the dreaded restore button. 

 

Thanks again!

 

Brian

 

Yes, a great community here!

 

Tom, thanks for taking the time to explain!  Have a great 4th! 

Turns out the "model" field is actually 20 16-bit words - doh!  Oh well, learned alot more about the libata code... 

 

That would explain why the "model" variable in the "mdp_device_descriptor" structure is 40 characters.

 

So we don't have to change the name of that button after all, right?

I think you are picking on me... :(   The button really needs to be re-labeled. 

 

How about changing it to "Delete Existing Disk Config" and the description can say "Delete the existing disk configuration and replace it with a new one based on the currently assigned and working disks."  Add an "Are you sure" checkbox, and I'll focus on the other issues. 

 

Joe L.

So we don't have to change the name of that button after all, right?

I think you are picking on me... :(   The button really needs to be re-labeled.

Joe L.

 

The button really really needs to be re-labeled.

Who was it that said Joe L. has the patience of Joeb??

 

I think with all his patience and all his support preventing people from making a grave mistake (and in his honor of such great support) the button should be renamed (and even relocated if need be). 

 

How about changing it to "Delete Existing Disk Config" and the description can say "Delete the existing disk configuration and replace it with a new one based on the currently assigned and working disks."  Add an "Are you sure" checkbox, and I'll focus on the other issues. 

 

I like that rename best methinks.

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).

 

Just posting the following findings from my more up-to-date v4.7 installation, to clarify for anyone else with a similar problem who has also located this thread.

 

My own situation was:

- UNRAID USB boot flash drive complete failure (no longer recognized).

- Needed to go back to a flash drive backup from prior to adding the latest disk to the array.

- Knew the parity was good so I just wanted to restore the config with good parity.

 

I followed the above with my v4.7 unRaid server, but after executing:

 mdcmd set invalidslot 99

 

I got NO response, instead of the described response:

 cmdOper=set
cmdResult=ok

 

However after further reading of various posts on this forum, I ascertained that NO response seemed to be the case for the newer unRaid versions (eg. 4.7 or 5.0 etc).

 

I also noted the important point documented by Tom in another recent thread:

Now click Start (don't do a refresh between typing this command clicking Start or else command will have no effect).

What this does is tell the driver that none of the array drives are invalid, and hence won't start a sync (normally Parity is marked invalid when there's been a "New Config").

 

ie. To summarize, you need to:

- Execute "mdcmd set invalidslot 99" (no response may be received).

- Ensure you DO NOT refresh the management browser page.

- Start the array.

- Just a Parity Check will now commence, instead of the full parity build that was indicated.

- If no parity errors are evident you can probably stop the check, or alternatively leave it to complete for peace of mind.

 

Hope this added information helps anyone with the same uncertainty I had, when the described response was NOT received to the "mdcmd set invalidslot 99" command.