Miles Nordin wrote: >>>>>> "c" == Miles Nordin <[EMAIL PROTECTED]> writes: >>>>>> > > c> Did you guys ever fix this, or get a bug number, or > c> anything? >
I think it is a bug. I haven't been able to produce it myself, so I won't file a bug on it, but recommend that anyone who encounters it do so. > I found two bugs about this: > > http://bugs.opensolaris.org/view_bug.do?bug_id=6736213 > http://bugs.opensolaris.org/view_bug.do?bug_id=6739532 > > I don't think either one fits either of your DEGRADED / import -f > problems. > > the first seems to be the result of a regression test, yet it's not > reproduceable. <confused> > > The second I think is mirrors only, not raidz, and has to do with an > unplayed ZIL and a regression induced by the fix for 6707530. > In b96, some changes were made to the handling of ZIL failures. If you are on b96, then this is likely to be a result of those changes, but FMA should log an e-report indicating the condition. Does fmadm faulty show a fault.fs.zfs.log_replay? If so, follow the instructions provided for the message provided. > > Also reading the comments for 6707530, it sounds like a ZIL read > problem makes a pool FAULTED but that it can be brought back online > with 'zpool clear'. This sounds bad because: > > a. You can't import a FAULTED pool, and you can't run 'zpool clear' > on an exported pool, so it's yet another chicken-and-egg problem > like these frustrating ``no valid replicas'' messages one gets all > the time and stupid obstinence in 'format' and 'fmthard'. > > b. 'zpool clear' is starting to mean too many different things. > > We already have problems with administration and bug reporting > because the user interfaces hide too much in the name of > ``simplicity''. > > I guess the point is to stop reading and writing to a pool, but allow > read/write to continue if the admin forces it. which is something > that's never ever supposed to happen to people who drink a lot of > Kool-Aid: always consistent on disk, no fsck tool, all maintenance > performed online. > > This new meaning of 'zpool clear' breaks Kool-Aid rules because it's > offline maintenance, and because it agrees there are two > interpretations to the state on the disk right now and the sysadmin > may choose between them. Both are totally fine with me---breaking the > rule is fine---but hiding such dirtyness inside a command used for > zeroing statistics seems politically-correct in the absolute worst > way, a way likely to surprise and confuse people. > I've never seen a Kool-Aid rule (and suspect that Miles is just being antisocial :-(. -- richard > If I wanted to hide the log-discarding feature in a > politically-correct way, I'd put it inside 'zpool import -f' rather > than 'zpool clear'. 'export / import -f' is the closest thing to > offline maintenance ZFS has so far. > > I also think it should be visible if a pool has unplayed log or not, > and maybe also to which filesystem the log pertains. I would ask for > a separate command to discard logs, but I know there's no way in hell > to get another zpool command added through the political machinery, so > what we should have is SOME way to know if we are tossing out a log or > not. If you don't want to disturb ``simplicity'' you can hide the > ZIL-dirty-indicator behind -vvv or something, like Microsoft's way of > stringing clutter along endless chains of [Advanced...] buttons. > > ------------------------------------------------------------------------ > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
