On Tue, May 27, 2008 at 1:50 PM, Eric Schrock <[EMAIL PROTECTED]> wrote: > 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. >
Thanks for the reply. As noted, I do recommend against the log device as you can't remove it and the replacement as you see is touchy at best. I know the larger, but general vdev evacuation is ongoing, but if it is simple, log evacuation would make logs useful now instead of waiting. > - 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
