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
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
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
Joe -
We definitely don't do great accounting of the 'vdev_islog' state here,
and it's possible to create a situation where the parent replacing vdev
has the state set but the children do not, but I have been unable to
reproduce the behavior you saw. I have rebooted the system during
resilver,
On Tue, May 27, 2008 at 4:50 PM, Eric Schrock [EMAIL PROTECTED] wrote:
Joe -
We definitely don't do great accounting of the 'vdev_islog' state here,
and it's possible to create a situation where the parent replacing vdev
has the state set but the children do not, but I have been unable to
Joe Little wrote:
On Tue, May 27, 2008 at 4:50 PM, Eric Schrock [EMAIL PROTECTED] wrote:
Joe -
We definitely don't do great accounting of the 'vdev_islog' state here,
and it's possible to create a situation where the parent replacing vdev
has the state set but the children do not, but I have
