Well, it worked for me, at least. Note that this is a very limited recovery case- it only works if you have the GUID of the slog device from zpool.cache, which in the case of a fail-on-export and reimport might not be available. The original author of the fix seems to imply that you can use any size device as the replacement slog, but I had trouble doing that. Didn't investigate enough to say conclusively that that is not possible, though. It's a very limited fix, but for the case Paul outlined, it will work, assuming zpool.cache is available.
On Thu, May 21, 2009 at 9:21 AM, Mike Gerdts <mger...@gmail.com> wrote: > On Wed, May 20, 2009 at 9:35 AM, Paul B. Henson <hen...@acm.org> wrote: > > On Wed, 20 May 2009, Darren J Moffat wrote: > > > >> Why do you think there is no progress ? > > > > Sorry if that's a wrong assumption, but I posted questions regarding it > to > > this list with no response from a Sun employee until yours, and the > > engineer assigned to my support ticket was unable to provide any > > information as to the current state or if anyone was working on it or why > > it was so hard to do. Barring any data to the contrary it appeared from > an > > external perspective that it was stalled. > > > >> The code for this is hard to implement. People are working on very hard > >> but that doesn't mean there isn't any progress if there is no eta or > >> workaround available via Sun Service. > > > > Why is it so hard? I understand that removing a data vdev or shrinking > the > > size of a pool is complicated, but what makes it so difficult to remove a > > slog? If the slog fails the pool returns to an embedded log, it seems the > > only difference between a pool with a failed slog and a pool with no slog > > is that the former knows it used to have a slog. Why is it not as simple > as > > updating the metadata for a pool with a failed slog so it no longer > thinks > > it has a slog? > > > > On another note, do you have any idea how one might recover from the case > > where a slog device fails while the pool is inactive and renders it > > inaccessible? > > > > Thanks... > > I stumbled across this just now while performing a search for something > else. > > http://opensolaris.org/jive/thread.jspa?messageID=377018 > > I have no idea of the quality or correctness of this solution. > > -- > Mike Gerdts > http://mgerdts.blogspot.com/ > _______________________________________________ > 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
