Jan Hellevik wrote:
Yes, I can try to do that. I do not have any more of this brand of disk, but I
guess that does not matter. It will have to wait until tomorrow (I have an
appointment in a few minutes, and it is getting late here in Norway), but I
will try first thing tomorrow. I guess a pool on a single drive will do the
trick? I can create the log as a partition on yet another drive just as I did
with the SSD (do not want to mess with it just yet). Thanks for helping!
In this case the specific brand and model of drive probably does not matter.
The most accurate test will be to setup a test pool as similar as
possible to the damaged pool, i.e. a 4 disk RAIDZ1 with a log on a
partition of a 5th disk.
A single drive pool might do the trick for testing, but it has no
redundancy. The smallest pool with redundancy is a mirror, thus the
suggestion to use a mirror. If you have enough spare/small/old drives
that are compatible with the second controller, use them to model your
damaged pool. For this test it doesn't really matter if these are 4 gb
or 40 gb or 400 gb drives.
Try the following things in order. Keep a copy of the terminal commands
you use and the command responses you get.
1.) Wipe (e.g. dban/dd/zero wipe) disks that will make up the test pool,
and create the test pool. Copy some test data to the pool, like an
OpenSolaris ISO file.
Try migrating the disks to the second controller the same way you did
with your damaged pool. Use the exact same steps in the same order.
See your notes/earlier posts while doing this to make sure you remember
them exactly.
If that works (a forced import will likely be needed), then you might
have had a one time error, or hard to reproduce error, or maybe did a
minor step slightly differently from how you remembered doing it with
the damaged pool.
If that fails, then you may have a repeatable test case.
2.) Wipe (e.g. dban/dd/zero wipe) disks that made up the test pool, and
recreate the test pool. Copy some test data to the pool, like an
OpenSolaris ISO file.
Try migrating the disks the recommended way, using export, powering
everything off, and then import.
If that works (without needed a forced import), then skipping the export
was likely a trigger.
If that fails, it seems like the second controller is doing something to
the disks. Look at the controller BIOS settings for something relevant
and see if there are any firmware updates available.
3.) If you have a third (different model) controller (or a another
computer running the same Solaris version with a different controller),
repeat step 2 with it. If step 2 failed but this works, that's more
evidence the second controller is up to something.
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
