> On 4. Nov 2019, at 03:42, Alexander Motin <mav...@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 _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
