Yeah, I noticed this the other day while I was working on an unrelated problem. The basic problem is that log devices are kept within the normal vdev tree, and are only distinguished by a bit indicating that they are log devices (and is the source for a number of other inconsistencies that Pwel has encountered).
When doing a replacement, the userland code is responsible for creating the vdev configuration to use for the newly attached vdev. In this case, it doesn't preserve the 'is_log' bit correctly. This should be enforced in the kernel - it doesn't make sense to replace a log device with a non-log device, ever. I have a workspace with some other random ZFS changes, so I'll try to include this as well. FWIW, removing log devices is significantly easier than removing arbitrary devices, since there is no data to migrate (after the current txg is synced). At one point there were plans to do this as a separate piece of work (since the vdev changes are needed for the general case anyway), but I don't know whether this is still the case. - Eric On Tue, May 27, 2008 at 01:13:47PM -0700, Joe Little wrote: > This past weekend, but holiday was ruined due to a log device > "replacement" gone awry. > > I posted all about it here: > > http://jmlittle.blogspot.com/2008/05/problem-with-slogs-how-i-lost.html > > In a nutshell, an resilver of a single log device with itself, due to > the fact one can't remove a log device from a pool once defined, cause > ZFS to fully resilver but then attach the log device as as stripe to > the volume, and no longer as a log device. The subsequent pool failure > was exceptionally bad as the volume could no longer be imported and > required read-only mounting of the remaining filesystems that I could > to recover data. It would appear that log resilvers are broken, at > least up to B85. I haven't seen code changes in this space so I > presume this is likely an unaddressed problem. > _______________________________________________ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss -- Eric Schrock, Fishworks http://blogs.sun.com/eschrock _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
