CVS commit: src/external/cddl/osnet/dist/uts/common/fs/zfs

["YAMAMOTO Takashi" <yamt%netbsd.org@localhost>]

Module Name:    src
Committed By:   yamt
Date:           Fri Mar 27 13:50:52 UTC 2026

Modified Files:
        src/external/cddl/osnet/dist/uts/common/fs/zfs: zfs_vfsops.c
            zfs_vnops.c

Log Message:
zfs: use 32-bit st_dev for stat(2)

while dev_t is 64-bit on NetBSD since the merge of
christos-time_t branch in 2009, we only use the lower
32-bit of it, at least for the purpose of specifying
a device in the kernel.

however, dev_t is also used as a file system id. eg. st_dev
reported by stat(2). as zfs has no device to naturally represent
its file system, currently it reports 56-bit guid of the file
system for the purpose.

unfortunately, some user applications still consider it as
a good old device id and assumes operations like
makedev(major(dev),minor(dev)) preserves the value.
it doesn't hold for NetBSD's implementation of makedev and
friends, which only honors the lower 32-bit of the dev_t.

this commit makes zfs report fsid with the high 32-bit zeros
to avoid the issues in such applications. namely, this fixes an
issue with rsync, reported by HIROSE yuuji on a japanese ML [1]
in 2024. you can find his reproduce recipe below. i was able to
reproduce the issue with rsync-3.4.1 from pkgsrc.

maybe we can "fix" our, at least userland-visible version of,
makedev and friends to provide full 64-bit round-trip as some
of other platforms do. (eg. glibc, freebsd)
although it might be an improvement and can benefit other things
like nfs v3, it isn't an alternative to this fix because it
doesn't fix existing application binaries built with the current
version of the macros.

note: this commit also changes statvfs f_fsid. as f_fsid is a long,
before this change, we were truncating the value only on 32-bit ports.

note: this commit doesn't change the "netbsd-extended" fsid
(f_fsidx), which is used for nfs file handles.

note: this commit would cause a flag day for applications which
somehow save st_dev of files. are there such applications?

note: this commit would increase the chance of fsid conflicts.
currently zfs ensures its fsids unique within zfs, but not with
other netbsd file systems. with this commit, there can be conflict
even within zfs. (mentioned in PR/60135)

```
rm -rf src
rm -rf dest
mkdir -p src/a/b/c
mkdir -p src/1/2/3
mkdir dest
rsync -avx --delete src dest
rm -r src/1
rsync -avx --delete src dest
test -d dest/src/1 && echo "this directory should have been removed"
```

[1] http://www.re.soum.co.jp/~jun/welcome.html#netbsd

related to PR/60135
https://gnats.netbsd.org/60135


To generate a diff of this commit:
cvs rdiff -u -r1.34 -r1.35 \
    src/external/cddl/osnet/dist/uts/common/fs/zfs/zfs_vfsops.c
cvs rdiff -u -r1.97 -r1.98 \
    src/external/cddl/osnet/dist/uts/common/fs/zfs/zfs_vnops.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.