Re: [zfs-discuss] zfs import -f not working!
Did you guys ever fix this, or get a bug number, or anything? Should I avoid that release? I was about to install b96 for ZFS fixes but this 'zpool import -f' problem looks bad. Corey -8- pr1# zpool offline tank c5t0d0s0 pr1# zpool status pool: rpool state: ONLINE scrub: none requested config: NAMESTATE READ WRITE CKSUM rpool ONLINE 0 0 0 c3t0d0s0 ONLINE 0 0 0 errors: No known data errors pool: tank state: DEGRADED status: One or more devices has been taken offline by the administrator. Sufficient replicas exist for the pool to continue functioning in a degraded state. action: Online the device using 'zpool online' or replace the device with 'zpool replace'. scrub: none requested config: NAME STATE READ WRITE CKSUM tank DEGRADED 0 0 0 raidz1 DEGRADED 0 0 0 c5t0d0s0 OFFLINE 0 0 0 c5t1d0s0 ONLINE 0 0 0 c5t2d0s0 ONLINE 0 0 0 c5t3d0s0 ONLINE 0 0 0 errors: No known data errors pr1# zpool export tank --- I then disabled SNDR replication. pr1# sndradm -g zfs-tank -d Disable Remote Mirror? (Y/N) [N]: Y - Then I try to import the ZPOOL on the secondary. -- pr2# zpool import pool: tank id: 9795707198744908806 state: DEGRADED status: One or more devices are offlined. action: The pool can be imported despite missing or damaged devices. The fault tolerance of the pool may be compromised if imported. config: tank DEGRADED raidz1 DEGRADED c5t0d0s0 OFFLINE c5t1d0s0 ONLINE c5t2d0s0 ONLINE c5t3d0s0 ONLINE pr2# zpool import tank cannot import 'tank': one or more devices is currently unavailable pr2# zpool import -f tank cannot import 'tank': one or more devices is currently unavailable pr2# --- Importing on the primary gives the same error. -8- Michael -8- svn97 x86 # zpool import pool: tank id: 7268271257490786210 state: DEGRADED status: The pool was last accessed by another system. action: The pool can be imported despite missing or damaged devices. The fault tolerance of the pool may be compromised if imported. see: http://www.sun.com/msg/ZFS-8000-EY config: tankDEGRADED raidz1DEGRADED c0d0s4 UNAVAIL cannot open c0d1s4 ONLINE c2t1d0 ONLINE c4t1d0 ONLINE c3t0d0 ONLINE c1t0d0 ONLINE c1t1d0 ONLINE c2t0d0 ONLINE raidz1ONLINE c3t1d0 ONLINE c4t3d0 ONLINE c4t2d0 ONLINE c4t0d0 ONLINE c4t4d0 ONLINE c4t5d0 ONLINE c4t6d0 ONLINE c4t7d0 ONLINE --- SNIP # zpool import tank cannot import 'tank': pool may be in use from other system, it was last accessed by (hostid: 0x985b235) on Sat Sep 6 12:04:16 2008 use '-f' to import anyway # zpool import -f tank cannot import 'tank': one or more devices is currently unavailable # -8- pgp9SzsknGdCY.pgp Description: PGP signature ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs import -f not working!
c == Miles Nordin [EMAIL PROTECTED] writes: c Did you guys ever fix this, or get a bug number, or c anything? 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. 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. 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. pgpjSgQHV3p7D.pgp Description: PGP signature ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs import -f not working!
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
[zfs-discuss] zfs import -f not working!
svn97 x86 # zpool import pool: tank id: 7268271257490786210 state: DEGRADED status: The pool was last accessed by another system. action: The pool can be imported despite missing or damaged devices. The fault tolerance of the pool may be compromised if imported. see: http://www.sun.com/msg/ZFS-8000-EY config: tankDEGRADED raidz1DEGRADED c0d0s4 UNAVAIL cannot open c0d1s4 ONLINE c2t1d0 ONLINE c4t1d0 ONLINE c3t0d0 ONLINE c1t0d0 ONLINE c1t1d0 ONLINE c2t0d0 ONLINE raidz1ONLINE c3t1d0 ONLINE c4t3d0 ONLINE c4t2d0 ONLINE c4t0d0 ONLINE c4t4d0 ONLINE c4t5d0 ONLINE c4t6d0 ONLINE c4t7d0 ONLINE --- SNIP # zpool import tank cannot import 'tank': pool may be in use from other system, it was last accessed by (hostid: 0x985b235) on Sat Sep 6 12:04:16 2008 use '-f' to import anyway # zpool import -f tank cannot import 'tank': one or more devices is currently unavailable # -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
