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:
tank DEGRADED
raidz1 DEGRADED
c0d0s4 UNAVAIL cannot open
c0d1s4 ONLINE
c2t1d0 ONLINE
c4t1d0 ONLINE
c3t0d0 ONLINE
c1t0d0 ONLINE
c1t1d0 ONLINE
c2t0d0 ONLINE
raidz1 ONLINE
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
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:
NAME STATE 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:
tank DEGRADED
raidz1 DEGRADED
c0d0s4 UNAVAIL cannot open
c0d1s4 ONLINE
c2t1d0 ONLINE
c4t1d0 ONLINE
c3t0d0 ONLINE
c1t0d0 ONLINE
c1t1d0 ONLINE
c2t0d0 ONLINE
raidz1 ONLINE
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<-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 304 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20080911/b639169c/attachment.bin>
>>>>> "c" == Miles Nordin <carton at Ivy.NET> 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 304 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20080911/02f40cd1/attachment.bin>
Miles Nordin wrote:>>>>>> "c" == Miles Nordin <carton at Ivy.NET> 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 at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >