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-head mailing list