>>>>> "rs" == Ross Smith <[EMAIL PROTECTED]> writes:
rs> 4. zpool status still reports out of date information.
I know people are going to skim this message and not hear this.
They'll say ``well of course zpool status says ONLINE while the pool
is hung. ZFS is patiently waiting. It doesn't know anything is
broken yet.'' but you are NOT saying it's out of date because it
doesn't say OFFLINE the instant you power down an iSCSI target.
You're saying:
rs> - After 3 minutes, the iSCSI drive goes offline.
rs> The pool carries on with the remaining two drives, CIFS
rs> carries on working, iostat carries on working. "zpool status"
rs> however is still out of date.
rs> - zpool status eventually
rs> catches up, and reports that the drive has gone offline.
so, there is a ~30sec window when it's out of date. When you say
``goes offline'' in the first bullet, you're saying ``ZFS must have
marked it offline internally, because the pool unfroze.'' but you
found that even after it ``goes offline'' 'zpool status' still
reports it ONLINE.
The question is, what the hell is 'zpool status' reporting? not the
status, apparently. It's supposed to be a diagnosis tool. Why should
you have to second-guess it and infer the position of ZFS's various
internal state machines through careful indirect observation, ``oops,
CIFS just came back,'' or ``oh sometihng must have changed because
zpool iostat isn't hanging any more''? Why not have a tool that TELLS
you plainly what's going on? 'zpool status' isn't.
Is it trying to oversimplify things, to condescend to the sysadmin or
hide ZFS's rough edges? Are there more states for devices that are
being compressed down to ONLINE OFFLINE DEGRADED FAULTED? Is there
some tool in zdb or mdb that is like 'zpool status -simonsez'? I
already know sometimes it'll report everything as ONLINE but refuse
'zpool offline ... <device>' with 'no valid replicas', so I think, yes
there are ``secret states'' for devices? Or is it trying to do too
many things with one output format?
rs> 5. When iSCSI targets finally do come back online, ZFS is
rs> resilvering all of them (again, this rings a bell, Miles might
rs> have reported something similar).
my zpool status is so old it doesn't say ``xxkB resilvered'' so I've
no indication which devices are the source vs. target of the resilver.
What I found was, the auto-resilver isn't sufficient. If you wait for
it to complete, then 'zpool scrub', you'll get thousands of CKSUM
errors on the dirty device, so the resilver isn't covering all the
dirtyness. Also ZFS seems to forget about the need to resilver if you
shut down the machine, bring back the missing target, and boot---it
marks everything ONLINE and then resilvers as you hit the dirty data,
counting CKSUM errors. This has likely been fixed between b71 and
b101. It's easy to test: (a) shut down one iSCSI target, (b) write to
the pool, (c) bring the iSCSI target back, (d) wait for auto-resilver
to finish, (e) 'zpool scrub', (f) look for CKSUM errors. I suspect
you're more worried about your own problems though---I'll try to
retest it soon.
pgpcvDMGKA1VP.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
