>>>>> "tn" == Thomas Nau <[EMAIL PROTECTED]> writes:
tn> I never experienced that one but we usually don't touch any of
tn> the iSCSI settings as long as a devices is offline. At least
tn> as long as we don't have to for any reason
Usually I do 'zpool offline' followed by 'iscsiadm remove
discovery-address ...'
This is for two reasons:
1. At least with my old crappy Linux IET, it doesn't restore the
sessions unless I remove and add the discovery-address
2. the auto-ONLINEing-on-discovery problem. Removing the discovery
address makes absolutely sure ZFS doesn't ONLINE something before
I want it to.
If you have to do this maintenance again, you might want to try
removing the discovery address for reason #2. Maybe when your iSCSI
target was coming back up, it bounced a bit. so, when the target was
coming back up, you might have done the equivalent of removing the
target without 'zpool offline'ing first (and then immediately plugging
it back in).
That's the ritual I've been using anyway. If anything unexpected
happens, I still have to manually scrub the whole pool to seek out all
these hidden ``checksum'' errors.
Hopefully some day you will be able to just look in fmdump and see
``yup, the target bounced once as it was coming back up.'' and
targets will be able to bounce as much as they like with
failmode=wait, or for short reasonable timeouts with other failmodes,
and automatically do fully-adequate but efficient resilvers with
proper dirty-region-logging without causing any latent checksum
errors. and zpool offline'd devices will stay offline until reboot as
promised, and will never online themselves. and iSCSI sessions will
always come up on their own without having to kick the initiator.
pgpPajiw7r2cN.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
