Problems with NSS partition mirroring and pool errors.

Question

OS: NetWare 6.5SP8 latest patches applied
I have an NSS pool that is made up of two 2TB LUNS on my SAN array.
I've been trying to move the pool from the LUNs on my SAN array to a pair of 2TB VMWare disks by using the partition mirror method.
All of the LUNS reside on the same array, but the two original LUNs are attached to an HBA in passthrough mode, so the VMWare infrastructure does not see those LUNS.
One partition mirrored without issue. The second one shows as synchronized yet remained at 99%.
A forum search indicated that a pool rebuild was in order.
I ran a pool verify and rebuild and tried mirroring the "problem child" partition again with the same result.
Before running the rebuild a second time, I removed both mirrored pairs.
I ran a pool verify and rebuild and tried mirroring the "problem child" partition again with the same result.
Last night, I repeated that same process and finally got 100% synchronization.
In the second and third rebuild processes, I got an error message stating that data would be lost if I continued the rebuild. Since I have backup, I continued the rebuild.
About 6 hours after that synchronization finished, I started receiving block error messages for the pool:
NSS-3.00-5002: Pool xxxx/DATA is being deactivated.
An error (20012(nameTree.c[45])) at block 536784421(file block -536784421)(ZID 6) has compromised volume integrity.
The pool deactivated itself.
I reset the server and when it mounted that volume, I continued to receive the errors.
I deactivated the pool, put it in maintenance mode and started another pool rebuild, this time with the /purge option.
I did not remove the mirrored pair before the rebuild started, so I have the one partition that gave me no problems un-mirrored and the partition that did give me problems is mirrored.
I don't know if that will have any affect on the rebuild process or not.
My questions are:
1) Will the fact that the pool is only half-mirrored be an issue for the rebuild?
2) Is there any other option in the rebuild process that I should have added?
3) Is the fact that I'm mirroring to a VMFS disk an issue? I could create a new pool/volume on those VMWare disks and use the server consolidation utility to copy the data between volumes, but my desire to avoid that was the reason to use the mirror process in the first place.

Answer 1

The difference between a sledge hammer and a Q-Tip is that you do a lot less damage with a Q-Tip.
Everything has been messed with to the point where it would be impossible for any other advice than make a new disk, make a new pool, make a new volume, and do your restore. Then, when all the data is restored without error, move the OLD DATA: volume out of the way and put in the NEW DATA: volume.
Originally Posted by gathagan
My questions are:
1) Will the fact that the pool is only half-mirrored be an issue for the rebuild?
2) Is there any other option in the rebuild process that I should have added?
3) Is the fact that I'm mirroring to a VMFS disk an issue? I could create a new pool/volume on those VMWare disks and use the server consolidation utility to copy the data between volumes, but my desire to avoid that was the reason to use the mirror process in the first place.
1. God only knows. It should not.
2. No. I think its an issue of doing too much, to quickly. It is unlikely a pool rebuild would "fix" a mirroring problem. I would not have gone ahead with a pool rebuild with mirroring broken.
3. A disk is a disk. Perhaps there is some underlying issue with the VMDK. How is it provisioned? Is it out of space? Buggy edge cases of having an extactly 2TB VMDK? Who knows.
The mirroring happens at a layer below the pool level. So I have a hard time understanding a how a rebuild would help mirroring unless the pool is really bent to begin with.
Again, the state of the current DATA: volume would be in question after all that fiddling, even if you can get it to work would you really trust it? I would not. I would recreate DATA: from backup on whatever new partition you want and chalk it up to experience. You can minimize the pain of that by restoring to a differently named volume and then renaming the volumes after you confirm proper operation.
-- Bob