Re: [PATCH] fs/zfs/zfs: Mark bookmark_v2 and bookmark_written as supported

--===============6801211161485389637==
Content-Type: multipart/alternative; boundary="00000000000005d2e40657eba8fe"

--00000000000005d2e40657eba8fe
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Maximo

We have moved to a GitLab MR based development workflow so please create an
MR instead.

Instructions are at:
https://gitlab.freedesktop.org/gnu-grub/grub/-/raw/master/CONTRIBUTING

Leo

On Fri, Jul 31, 2026 at 1:11=E2=80=AFAM Maximo Guk via Grub-devel <
[email protected]> wrote:

> We don't need any actual adjustments as we don't use the affected
> structures.
>
> Both features are read-incompatible - they are registered without
> ZFEATURE_FLAG_READONLY_COMPAT and are therefore recorded in the pool's
> features_for_read - so check_mos_features() refuses to mount any pool whe=
re
> either is active. Neither affects a structure GRUB reads:
> com.datto:bookmark_v2 only enlarges bookmark objects and
> com.delphix:bookmark_written only adds bookmark accounting fields, while
> GRUB
> never enumerates bookmarks. Note that com.delphix:bookmarks itself is
> READONLY_COMPAT and so never appears in features_for_read.
>
> This follows commit c464f1ec3 (fs/zfs/zfs: Mark vdev_zaps_v2 and
> head_errlog
> as supported), which added com.delphix:head_errlog - likewise recorded in
> features_for_read and likewise unused by GRUB.
>
> Signed-off-by: Maximo Guk <[email protected]>
> ---
> Found this when a nightly ZFS send/recv backup created a bookmark on the
> pool
> holding /boot. The machine ran fine that day and simply failed to boot on
> the
> next restart, with nothing to indicate what had changed.
>
> Reproduced on Ubuntu 26.04 (GRUB 2.14, OpenZFS 2.4.1), single-pool ZFS
> root:
> creating a bookmark makes "grub-probe --target=3Dfs /" fail (the same
> check_mos_features() path used at boot), and destroying it restores both
> the
> feature state and booting.
>
> This is not specific to one backup tool - zrepl, sanoid/syncoid and
> zfs-autobackup all create bookmarks to anchor incremental sends without
> retaining snapshots. zrepl carries an open issue for the same interaction=
:
> https://github.com/zrepl/zrepl/issues/501
>
> Earlier discussion of GRUB's feature allowlist, including a proposal to
> relax
> check_mos_features() wholesale (this patch is the narrower alternative):
> https://github.com/openzfs/zfs/discussions/15169
>
> Happy to test any alternative approach.
>
>  grub-core/fs/zfs/zfs.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/grub-core/fs/zfs/zfs.c b/grub-core/fs/zfs/zfs.c
> index 83dfa6d52..5d0c50b69 100644
> --- a/grub-core/fs/zfs/zfs.c
> +++ b/grub-core/fs/zfs/zfs.c
> @@ -296,6 +296,8 @@ static const char *spa_feature_names[] =3D {
>    "com.klarasystems:vdev_zaps_v2",
>    "com.delphix:head_errlog",
>    "org.freebsd:zstd_compress",
> +  "com.datto:bookmark_v2",
> +  "com.delphix:bookmark_written",
>    NULL
>  };
>
> --
> 2.53.0
>
> _______________________________________________
> Grub-devel mailing list
> [email protected]
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
>

--00000000000005d2e40657eba8fe
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Maximo<div><br></div><div>We have moved to a GitLab MR =
based development workflow so please create an MR instead.=C2=A0</div><div>=
<br></div><div>Instructions=C2=A0are at:=C2=A0<a href=3D"https://gitlab.fre=
edesktop.org/gnu-grub/grub/-/raw/master/CONTRIBUTING">https://gitlab.freede=
sktop.org/gnu-grub/grub/-/raw/master/CONTRIBUTING</a></div><div><br></div><=
div>Leo</div></div><br><div class=3D"gmail_quote gmail_quote_container"><di=
v dir=3D"ltr" class=3D"gmail_attr">On Fri, Jul 31, 2026 at 1:11=E2=80=AFAM =
Maximo Guk via Grub-devel &lt;<a href=3D"mailto:[email protected]">grub-de=
[email protected]</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">We don&#39;t need any actual adjustments as we don&#39;t use the=
 affected structures.<br>
<br>
Both features are read-incompatible - they are registered without<br>
ZFEATURE_FLAG_READONLY_COMPAT and are therefore recorded in the pool&#39;s<=
br>
features_for_read - so check_mos_features() refuses to mount any pool where=
<br>
either is active. Neither affects a structure GRUB reads:<br>
com.datto:bookmark_v2 only enlarges bookmark objects and<br>
com.delphix:bookmark_written only adds bookmark accounting fields, while GR=
UB<br>
never enumerates bookmarks. Note that com.delphix:bookmarks itself is<br>
READONLY_COMPAT and so never appears in features_for_read.<br>
<br>
This follows commit c464f1ec3 (fs/zfs/zfs: Mark vdev_zaps_v2 and head_errlo=
g<br>
as supported), which added com.delphix:head_errlog - likewise recorded in<b=
r>
features_for_read and likewise unused by GRUB.<br>
<br>
Signed-off-by: Maximo Guk &lt;<a href=3D"mailto:[email protected]" target=3D"_b=
lank">[email protected]</a>&gt;<br>
---<br>
Found this when a nightly ZFS send/recv backup created a bookmark on the po=
ol<br>
holding /boot. The machine ran fine that day and simply failed to boot on t=
he<br>
next restart, with nothing to indicate what had changed.<br>
<br>
Reproduced on Ubuntu 26.04 (GRUB 2.14, OpenZFS 2.4.1), single-pool ZFS root=
:<br>
creating a bookmark makes &quot;grub-probe --target=3Dfs /&quot; fail (the =
same<br>
check_mos_features() path used at boot), and destroying it restores both th=
e<br>
feature state and booting.<br>
<br>
This is not specific to one backup tool - zrepl, sanoid/syncoid and<br>
zfs-autobackup all create bookmarks to anchor incremental sends without<br>
retaining snapshots. zrepl carries an open issue for the same interaction:<=
br>
<a href=3D"https://github.com/zrepl/zrepl/issues/501" rel=3D"noreferrer" ta=
rget=3D"_blank">https://github.com/zrepl/zrepl/issues/501</a><br>
<br>
Earlier discussion of GRUB&#39;s feature allowlist, including a proposal to=
 relax<br>
check_mos_features() wholesale (this patch is the narrower alternative):<br=
>
<a href=3D"https://github.com/openzfs/zfs/discussions/15169" rel=3D"norefer=
rer" target=3D"_blank">https://github.com/openzfs/zfs/discussions/15169</a>=
<br>
<br>
Happy to test any alternative approach.<br>
<br>
=C2=A0grub-core/fs/zfs/zfs.c | 2 ++<br>
=C2=A01 file changed, 2 insertions(+)<br>
<br>
diff --git a/grub-core/fs/zfs/zfs.c b/grub-core/fs/zfs/zfs.c<br>
index 83dfa6d52..5d0c50b69 100644<br>
--- a/grub-core/fs/zfs/zfs.c<br>
+++ b/grub-core/fs/zfs/zfs.c<br>
@@ -296,6 +296,8 @@ static const char *spa_feature_names[] =3D {<br>
=C2=A0 =C2=A0&quot;com.klarasystems:vdev_zaps_v2&quot;,<br>
=C2=A0 =C2=A0&quot;com.delphix:head_errlog&quot;,<br>
=C2=A0 =C2=A0&quot;org.freebsd:zstd_compress&quot;,<br>
+=C2=A0 &quot;com.datto:bookmark_v2&quot;,<br>
+=C2=A0 &quot;com.delphix:bookmark_written&quot;,<br>
=C2=A0 =C2=A0NULL<br>
=C2=A0};<br>
<br>
-- <br>
2.53.0<br>
<br>
_______________________________________________<br>
Grub-devel mailing list<br>
<a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]<=
/a><br>
<a href=3D"https://lists.gnu.org/mailman/listinfo/grub-devel" rel=3D"norefe=
rrer" target=3D"_blank">https://lists.gnu.org/mailman/listinfo/grub-devel</=
a><br>
<br>
</blockquote></div>

--00000000000005d2e40657eba8fe--



--===============6801211161485389637==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KR3J1Yi1kZXZl
bCBtYWlsaW5nIGxpc3QKR3J1Yi1kZXZlbEBnbnUub3JnCmh0dHBzOi8vbGlzdHMuZ251Lm9yZy9t
YWlsbWFuL2xpc3RpbmZvL2dydWItZGV2ZWwK

--===============6801211161485389637==--