Hello Bill,
BM> the sad reality comes when a reboot or export of the pool occurs
BM> and there is then no way to re-import the pool without re-inserting
BM> the missing ZIL device, and if the missing ZIL device is no longer
BM> available, the pool is inaccessible ... it's too late now to do a re
Thanks to Kyle, richard and Eric
In dealing with this problem, I realize now that I could have
saved myself a lot of grief if I had simply used the replace
command and substituted some other drive for my flash
drive before I removed it
I think that this point is critical for anyone who finds t
The problem is that the ZIL device is treated just like another toplevel
vdev. As part of the import process, we find all vdevs and assemble the
config, and verify that the sum of all vdev GUIDs match the expected
sum. Now, each vdev only stores enough configuration to keep track of
the toplevel
Perhaps this is being tracked as 6538021?
http://bugs.opensolaris.org/view_bug.do?bug_id=6538021
-- richard
Bill Moloney wrote:
> This is a re-post of this issue ... I didn't get any replies to the previous
> post of 12/27 ... I'm hoping someone is back from holiday
> who may have some insight in
Bill Moloney wrote:
> Taking it out does not impact the immediate function of the pool,
> but the inability to re-import it after this event is a significant issue.
> Has
> anyone found a workaround for this problem ? I have data in a pool that
> I cannot import because the separate zil is no lon
This is a re-post of this issue ... I didn't get any replies to the previous
post of 12/27 ... I'm hoping someone is back from holiday
who may have some insight into this problem ... Bill
when I remove a separate zil disk from a pool, the pool continues to function,
logging synchronous writes to t
