svn commit: r354283 - in head: stand/libsa/zfs sys/cddl/boot/zfs
Toomas Soome
tsoome at me.com
Mon Nov 4 06:31:07 UTC 2019
> On 4. Nov 2019, at 03:42, Alexander Motin <mavbsd at gmail.com> wrote:
>
> On 03.11.2019 20:19, Xin Li wrote:
>> On 2019-11-03 15:30, Ravi Pokala wrote:
>>> Uh....
>>>
>>> I've had a log device in my boot-pool for months, and have booted without issue:
>>>
>>> [threepio:~] rpokala% zpool status zroot
>>> pool: zroot
>>> state: ONLINE
>>> scan: scrub repaired 0 in 0 days 00:04:36 with 0 errors on Mon Oct 28 03:10:59 2019
>>> config:
>>>
>>> NAME STATE READ WRITE CKSUM
>>> zroot ONLINE 0 0 0
>>> nvd1p4 ONLINE 0 0 0
>>> logs
>>> nvd0p1 ONLINE 0 0 0
>>>
>>> errors: No known data errors
>>
>>
>> This is not supported, and it's not trivial to support it, because in
>> order to support it, the bootloader would have to know how to replay
>> zilogs, which would add quite a lot of code to it.
>
> The issue with ZIL not being replayed in case of read-only mount has
> nothing to do with the fact of SLOG device presence. The issue is the
> same when ZIL resides on the main disks of the pool. So while
> everything else you said is right, I see no any reason to ban pools with
> SLOG devices in this context.
>
Yep, indeed. I got myself confused from the fact we return EIO for log device. So a bit more cleanup is in order.
However, the big question there is not about how recent update the boot files have. To read out the boot files, we need a bit of processing done and to understand if those structures are consistent or not. But as I wrote before, thats something to be investigated.
rgds,
toomas
More information about the svn-src-all
mailing list