Date: Mon, 4 Nov 2019 08:31:01 +0200 From: Toomas Soome <tsoome@me.com> To: Alexander Motin <mavbsd@gmail.com> Cc: d@delphij.net, Ravi Pokala <rpokala@freebsd.org>, Toomas Soome <tsoome@FreeBSD.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r354283 - in head: stand/libsa/zfs sys/cddl/boot/zfs Message-ID: <DC0ACD75-E77C-4C25-9159-C2CE15B4FB8D@me.com> In-Reply-To: <cb846ed5-319f-7ef6-0604-047c5f3009b5@gmail.com> References: <201911031325.xA3DPl3B080386@repo.freebsd.org> <AC86E653-444A-4EBD-8379-BBA53BD160D3@panasas.com> <61bed957-a0c5-bb95-8138-13d00df9d44f@delphij.net> <cb846ed5-319f-7ef6-0604-047c5f3009b5@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 4. Nov 2019, at 03:42, Alexander Motin <mavbsd@gmail.com> wrote: >=20 > On 03.11.2019 20:19, Xin Li wrote: >> On 2019-11-03 15:30, Ravi Pokala wrote: >>> Uh.... >>>=20 >>> I've had a log device in my boot-pool for months, and have booted = without issue: >>>=20 >>> [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: >>>=20 >>> NAME STATE READ WRITE CKSUM >>> zroot ONLINE 0 0 0 >>> nvd1p4 ONLINE 0 0 0 >>> logs >>> nvd0p1 ONLINE 0 0 0 >>>=20 >>> errors: No known data errors >>=20 >>=20 >> 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. >=20 > 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. >=20 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DC0ACD75-E77C-4C25-9159-C2CE15B4FB8D>