data rebuild question

[garycase]

For my own reference, what is that procedure?

 

The original disk had been removed --

...this is the detail of what happened:

...

3) shut down array powered off and replaced disk 1 (2tb) with new 3tb precleared disk

...

 

... so all that needed to be done was to replace the original disk;  do a New Config with the Trust Parity option;  Start the array; Stop the array; unassign the original disk; Start the array again so it's shown as missing;  then Shut down; replace the disk with the new one;  boot; assign the new disk in disk1's place; and then Start the array and allow the rebuild to proceed.

 

As I noted earlier, this only works if there have been NO writes to the array.

 

 

Also, I'm curious as to exactly when we would have switched the disk settings from XFS back to Reiser in order to salvage the data.  Prior to running reiserfsck or after?

 

Nothing to change -- a rebuild would have used the original file system.    That option should NOT have even been present ... it was apparently due to the failure to first force the disk to appear "missing".

 

 

[Squid]

... so all that needed to be done was to replace the original disk;  do a New Config with the Trust Parity option;  Start the array; Stop the array; unassign the original disk; Start the array again so it's shown as missing;  then Shut down; replace the disk with the new one;  boot; assign the new disk in disk1's place; and then Start the array and allow the rebuild to proceed.

 

As I noted earlier, this only works if there have been NO writes to the array.

But a new config with the original drive with Trust Parity wouldn't work because parity is already out to lunch because of the format.  Writes have already happened because of the format.  What you would have to do is rebuild parity with the original drive (which may or may not drop dead at any point) so that you could then rebuild it onto a replacement drive.

 

IE: Formatting a drive does not just zero out certain locations (which would mean that the parity info is correct)  It also creates the basic file tables, etc.  Parity is going to be identical in the locations where both Reiser and XFS stored a 0 or 1.  Where Reiser and XFS differ in the bit that they are writing, parity is going to change.  The rebuilt drive will be XFS because of this.

 

Unless of course formatting a data disk at any time does NOT update parity information reflecting the format.  And if that's the case thats a huge defect

 

(or you're assuming that I don't know how to properly rebuild a disk  )

 

Also, I'm curious as to exactly when we would have switched the disk settings from XFS back to Reiser in order to salvage the data.  Prior to running reiserfsck or after?

Nothing to change -- a rebuild would have used the original file system.    That option should NOT have even been present ... it was apparently due to the failure to first force the disk to appear "missing".

No.  It was due to selecting XFS as the drive format instead of leaving it at either auto or Reiser

 

 

 

The fundamental problem is not about switching the file system during a rebuild.  Its all about switching a file system when the drive already has data on it.  The warnings are not blatant enough that you will lose all data on the drive - In the "defect report" I posted an option that will work for all situations where the user switches the file system and is presented with the format button

 

 

 

[garycase]

Indeed selecting the format option did in fact invalidate parity ... whether it was actually formatting the new drive or formatting the emulating drive doesn't matter -- the writes associated with the format meant the parity drive was no longer valid.

 

In that case the best alternatives were to (a) try a New Config with the original drive (but NOT "Trust Parity") and see if a parity sync could complete successfully (this often happens when you have re-seated a drive); or, if that doesn't work, then (b) do a Reiserfsck (which apparently was tried); or, finally © simply attach the old drive and see what data can be simply read from it (in this case it was apparently quite a bit).

 

The best choice, of course, is to simply copy the data from the failed drive to the reconstituted array from your backups -- but many folks don't consider their data important enough to backup ... at least not until they actually lose some of it 

[Squid]

a - In this case not really a good option because of the unknown status of the drive

 

My vote was always for c

 

OP decided to go with b and then c

 

Either way OP happy due to successfully recovering data, and he'll probably never make that mistake again.