Hi,

Testing how ZFS reacts to a failed disk can be difficult to anticipate
because some systems don't react well when you remove a disk. On an
x4500, for example, you have to unconfigure a disk before you can remove
it.

Before removing a disk, I would consult your h/w docs to see what the
recommended process is for removing components.

Swapping disks between the main pool and the spare pool isn't an
accurate test of a disk failure and a spare kicking in.

If you want to test a spare in a ZFS storage pool kicking in, then yank a disk from the main pool (after reviewing your h/w docs) and observe the spare behavior. If a disk fails in real time, I doubt it will be
when the pool is exported and the system is shutdown.

In general, ZFS pools don't need to be exported to replace failed disks.
I've seen unpredictable behavior when devices/controllers change on live pools. I would review the doc pointer I provided for recommended disk
replacement practices.

I can't comment on the autoreplace behavior with a pool exported and
a swap of disks. Maybe someone else can. The point of the autoreplace
feature is to allow you to take a new replacement disk and automatically
replace a failed disk without having to use the zpool replace command.
Its not a way to swap existing disks in the same pool.

Cindy

On 02/01/10 14:27, Tonmaus wrote:
Hi Cindys,

I'm still
not sure if you  physically swapped c7t11d0 for c7t9d0 or if c7t9d0 is
still connected and part of your pool.

The latter is not the case according to status, the first is definitely the case. format reports the drive as present and correctly labelled.
ZFS has recommended ways for swapping disks so if the pool is exported, the system shutdown and then disks are swapped, then the behavior is unpredictable and ZFS is understandably confused about what happened.
It might work for some hardware, but in general, ZFS should be notified of the 
device changes.

For the record, ZFS seems to be only marginally confused: The pool showed no 
errors after the import; the rest remains to be seen after scrub is done. I 
can't see what would be wrong with a clean export/import. And the results of 
the drive swap are part of the plan to find out what impact the HW has on the 
transfer of this pool.


You might experiment with the autoreplace pool
property. Enabling this
property will allow you to replace disks without
using the zpool replace command. If autoreplace is enabled, then physically
swapping out an
active disk in the pool with a spare disk that is is
also connected to
the pool without using zpool replace is a good
approach.

Does this still apply if I did a clean export before the swap?

Regards,

Tonmaus
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to