on 13/11/2012 18:16 Guido Falsi said the following:
> My idea, but is just a speculation, i could be very wrong, is that the geom
> tasting code has some problem with multiple vdev root pools.
Guido,
you are absolutely correct. The code for reconstructing/tasting a root pool
configuration is a modified upstream code, so it inherited a limitation from it:
the support for only a single top-level vdev in a root pool.
I have an idea how to add the missing support, but it turned out not to be
something that I can hack together in couple of hours.
> on 13/11/2012 18:16 Guido Falsi said the following:
>> My idea, but is just a speculation, i could be very wrong, is that the geom
>> tasting code has some problem with multiple vdev root pools.
> Guido,
> you are absolutely correct. The code for reconstructing/tasting a root pool
> configuration is a modified upstream code, so it inherited a limitation from it:
> the support for only a single top-level vdev in a root pool.
> I have an idea how to add the missing support, but it turned out not to be
> something that I can hack together in couple of hours.
I can imagine, it does not look simple in any way!
> Just to confirm, since I am holding back an update pending on this.
> If I have a raidz root pool, with three disks, like this:
> NAME STATE READ WRITE CKSUM
> zroot ONLINE 0 0 0
> raidz1-0 ONLINE 0 0 0
> gpt/disk0 ONLINE 0 0 0
> gpt/disk1 ONLINE 0 0 0
> gpt/disk2 ONLINE 0 0 0
> Then I'm fine to update without issues. the problem is only if, as an
> example, you have a mirror with striped disks, or a stripe with mirrored
> disks, which it seems to me the original poster had.
> Am I correct, and therefore ok to update?
Yes, looks like that. The affected system pool looks like this:
> On 11/16/12 16:45, Andriy Gapon wrote:
>> on 13/11/2012 18:16 Guido Falsi said the following:
>>> My idea, but is just a speculation, i could be very wrong, is that >>> the geom
>>> tasting code has some problem with multiple vdev root pools.
>> Guido,
>> you are absolutely correct. The code for reconstructing/tasting a >> root pool
>> configuration is a modified upstream code, so it inherited a >> limitation from it:
>> the support for only a single top-level vdev in a root pool.
>> I have an idea how to add the missing support, but it turned out not >> to be
>> something that I can hack together in couple of hours.
> I can imagine, it does not look simple in any way!
>> The patch also fixes a minor (single-time) memory leak.
>> Guido, Bartosz,
>> could you please test the patch?
> I have just compiler an r242910 kernel with this patch (and just this > one) applied.
> System booted so it seems to work fine! :)
I've just compiled and installed fresh kernel with your patch, system booted without any problems, so apparently patch works as intended.
Good job Andriy!
on 18/11/2012 02:26 Bartosz Stec said the following:
> W dniu 2012-11-16 17:17, Guido Falsi pisze:
>> On 11/16/12 16:45, Andriy Gapon wrote:
>>> Guido, Bartosz,
>>> could you please test the patch?
>> I have just compiler an r242910 kernel with this patch (and just this one)
>> applied.
>> System booted so it seems to work fine! :)
> I've just compiled and installed fresh kernel with your patch, system booted
> without any problems, so apparently patch works as intended.
Thank you both very much for testing!
Committed as r243213.
> on 18/11/2012 02:26 Bartosz Stec said the following:
>> W dniu 2012-11-16 17:17, Guido Falsi pisze:
>>> On 11/16/12 16:45, Andriy Gapon wrote:
>>>> Guido, Bartosz,
>>>> could you please test the patch?
>>> I have just compiler an r242910 kernel with this patch (and just this one)
>>> applied.
>>> System booted so it seems to work fine! :)
>> I've just compiled and installed fresh kernel with your patch, system booted
>> without any problems, so apparently patch works as intended.
> Thank you both very much for testing!
> Committed as r243213.
It adds support for multi-vdev root pool probing in kernel.
The best way to test is to remove zpool.cache before rebooting (but make sure to
keep a copy somewhere and be able to recover). I'd use a boot environment (a
root filesystem clone) for this.
---
Best regards, Andrei Lavreniyuk.
_______________________________________________
freebsd-curr...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Are there any other unusual messages before this line?
Could you please try adding vfs.zfs.debug=1 to loader.conf and check again?
Could you also provide 'zdb -CC zsolar' output and 'zdb -l /dev/gpt/diskX' for
each of the disks. These could be uploaded somewhere as they can be quite lengthy.
on 20/11/2012 12:45 Andrei Lavreniyuk said the following:
> Hi!
>> Are there any other unusual messages before this line?
>> Could you please try adding vfs.zfs.debug=1 to loader.conf and check again?
>> Could you also provide 'zdb -CC zsolar' output and 'zdb -l /dev/gpt/diskX' for
>> each of the disks. These could be uploaded somewhere as they can be quite lengthy.
> Please view attached files.
Thank you.
"Can not parse the config for pool" message explains what happens but not why...
> on 20/11/2012 17:06 Andriy Gapon said the following:
>> on 20/11/2012 16:59 Andrei Lavreniyuk said the following:
>>>>> Sorry to make you jump through so many hoops.
>>>>> Now that I see that the probed config is entirely correct, the problem appears to
>>>>> be quite obvious: vdev_alloc is not able to properly use spa_version in this
>>>>> context because spa_ubsync is not initialized yet.
