Re: zfs questions

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> Date: Fri, 20 Feb 2026 17:09:59 +0900
> From: Takashi YAMAMOTO <yamt9999%gmail.com@localhost>
> 
> recently i have used netbsd zfs and have a few questions.
> 
> * what's the purpose of zfs_zget_cleaner/VN_RELE_CLEANER?
>   i have read the explanation in
> https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=59885 .
>   but i don't understand why we want to avoid the normal zfs_zget in
> the first place.
>   for me, it seems working w/o these special versions of functions:
>   https://github.com/yamt/netbsd-src/commit/438ec29437465e0b7e2b831d4452159f83cad0cf
>   (i will attach the same patch to this mail for those who don't like github.)

If I recall correctly, a vnode with pending writes queued up for the
zil may become inactive and marked for reclamation _before_
zfs_get_data runs to issue those writes to the zil.

At that point, the NetBSD vnode life cycle forbids acquiring a new
reference, so instead of returning the old vnode, vcache_get will wait
for concurrent references to the vnode to drain and then create a new
vnode initialized with VFS_LOADVNODE.

I'm fuzzy on what happens at that point (hannken@ or chs@ may remember
better than I can), but I suspect it will be one of:

1. data associated with the old vnode (via the old v_data, the znode)
   will be silently lost; or

2. the existence of two znode identities for the same object leads zfs
   to trip over its own shoelaces, corrupting data and/or crashing; or

3. reclamation also blocks until the zil is committed, which is
   waiting in vcache_get for reclamation to finish, so it deadlocks.

Using zfs_zget_cleaner bypasses vcache_get to obtain the znode for the
purpose of zfs_get_data, provided that the caller guarantees it is
safe to hold the znode.  And the caller can only guarantee it is safe
if zfs_get_data runs before the vnode is reclaimed.

> * is anyone using zfs in netbsd seriously? :-)

I have been using it exclusively on my personal laptop and for my
NetBSD builds and pkgsrc bulk builds since 2020.  Last time I hit
issues that appeared to be related to zfs was around 2022 when I had
bad RAM in my laptop.

> * does anyone have a plan to update the codebase to recent openzfs?

Well, `plan' may be too strong a word, but yes, we absolutely should.