Is there any chance that the second controller wrote something onto the
disks when it saw the disks attached to it, thus corrupting the ZFS
drive signatures or more?
I've heard that some controllers require drives to be initialized by
them and/or signatures written to drives by them. Maybe your second
controller wrote to the drives without you knowing about it. If you
have a pair of (small) spare drives, make a ZFS mirror out of them and
try to recreate the problem by repeating your steps on them.
If you can recreate the problem, try to narrow it down to whether the
problem is caused by the second controller changing things, or if the
skipped zfs export is playing a role. I think the skipped zfs export
might have lead to zfs import needing to be forced (-f), but as long as
you weren't trying to access the disks from two systems at the same time
it shouldn't have been catastrophic. Forcing shouldn't be necessary if
things are being handled cleanly and correctly.
My hunch is the second controller did something when it saw the drives
connected to it, particularly if the second controller was configured in
RAID mode rather than JBOD or passthrough. Or maybe you changed some
settings on the second controller's BIOS that caused it to write to the
drives while you were trying to get things to work?
I've seen something similar by the BIOS on a Gigabyte X38 chipset
motherboard that has "Quad BIOS". This is partly documented by Gigabyte at
http://www.gigabyte.com.tw/FileList/NewTech/2006_motherboard_newtech/how_does_quad_bios_work_dq6.htm
From my testing, the BIOS on this board writes a copy of itself using
an HPA (Host Protected Area) to a hard drive for BIOS recovery purposes
in case of a bad flashing/BIOS upgrade. There is no prompting for the
writing, it appears to simply happen to whichever drive was the first
one connected to the PC, which is usually the current boot drive. On a
new clean disk, this would be harmless, but it risks data loss when
reusing drives or transferring drives between systems. This behavior is
able to cause data loss and has affected people using Windows Dynamic
Disks and UnRaid as can be seen by searching Google for "Gigabyte HPA".
More details:
As long as that drive is connected to the PC, the BIOS recognizes it as
being the 'recovery' drive and doesn't write to another drive. If that
drive is removed, then another drive will have an HPA created on it.
The easiest way to control this is to initially have just one drive
connected...the one you don't mind the HPA being placed on. Then you
can add the other drives without them being modified.
The HPA is created on 2113 sectors at the end of the drive. HDAT (a low
level drive diag/repair/config utility) cannot remove this HPA while the
drive is still the first drive (the BIOS must be enforcing protection of
that area). Making this drive a secondary drive by forcing the BIOS to
create another HPA on another drive allows HDAT to remove the HPA.
Manually examining the last 2114 (one more for good measure) sectors
will now show that it contains a BIOS backup image.
Other observations:
Device order in Linux (e.g. /dev/sda /dev/sdb) made no difference to
where the HPA ended up.
Jan Hellevik wrote:
Yes, I turned the system off before I connected the disks to the other
controller. And I turned the system off beore moving them back to the original
controller.
Now it seems like the system does not see the pool at all.
The disks are there, and they have not been used so I do not understand why I
cannot see the pool anymore.
Short version of what I did (actual output is in the original post):
zpool status -> pool is there but unavailable
zpool import -> pool already created
zpool export -> I/O error
format
cfgadm
zpool status -> pool is gone......
It seems like the pool vanished after cfgadm?
Any pointers? I am really getting worried now that the pool is gone for good.
What I do not understand is why it is gone - the disks are still there, so it
should be possible to import the pool?
What am I missing here? Any ideas?
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
