On Tue, May 27, 2008 at 5:04 PM, Neil Perrin <[EMAIL PROTECTED]> wrote:
> 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
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
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
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, ma
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
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 ha
