Date: Sun, 07 May 2023 21:39:21 +0000 From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 271292] kernel panic while dd'ing a USB disk to a ZFS directory Message-ID: <bug-271292-3630-HpfsVMSPly@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-271292-3630@https.bugs.freebsd.org/bugzilla/> References: <bug-271292-3630@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D271292 --- Comment #14 from Mark Millard <marklmi26-fbsd@yahoo.com> --- (In reply to dgilbert from comment #13) Of the following features, which are active? ( These are ones added after what is listed in /usr/share/zfs/compatibility.d/openzfs-2.1-freebsd ) edonr zilsaxattr head_errlog blake3 block_cloning I do not know just when main started supporting each of these. (The list has grown over time.) Presuming one knew for the Feb-13 kernel that you reference . . . (I expect that, for FreeBSD, blake3 and block_cloning may be the new ones vs. Feb-13. But I do not know for sure.) Any active "not even read-only compatible" feature is sufficient to block access. Absent such, any active "just read-only compatible" feature is sufficient to block write access. block_cloning is read-only compatible with an older zfs that does not support it. The pool will go back to just enabled status when the last cloned block is freed. (Not that one can directly cause such freeing, as far as I know.) blake3 being active is not even read-only compatible with an older zfs that does not support it. blake3 status is per dataset/filesystem. The pool will go back to just enabled status once all filesystems that have ever had their checksum set to blake3 are destroyed. head_errlog being active is not even read-only compatible with an older zfs that does not support it. Once active can not be put back to enabled for the pool. zilsxattr is read-only compatible with an older zfs that does not support it. zilsaxattr status is per dataset/filesystem. The pool will go back to just enabled status when all datasets that use the feature have been destroyed. edonr being active is not even read-only compatible with an older zfs that does not support it. edonr status is per dataset/filesystem. The pool will go back to just enabled status once all filesystems that have ever had their checksum set to edonr are destroyed. REMINDER (quoting): active This feature's on-disk format changes are in effect on the pool. Support for this feature is required to import the pool in read-write mode. If this fea= ture is not read-only compatible, support is also required to import the pool in read-only mode (see Read-only compatibility). enabled An administrator has marked this feature as enabled on the pool, but the feature's on-disk format changes have not been made yet. The pool can still= be imported by software that does not support this feature, but changes may be made to the on-disk format at any time which will move the feature to the active state. Some features may support returning to the enabled state after becoming active. See feature-specific documentation for details. disabled This feature's on-disk format changes have not been made and will not be ma= de unless an administrator moves the feature to the enabled state. Features ca= nnot be disabled once they have been enabled. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-271292-3630-HpfsVMSPly>