At least: <https://docs.freebsd.org/en/books/handbook/zfs/#zfs-advanced-tuning-vdev-trim_on_init> > vfs.zfs.vdev.trim_on_init $ uname -KU 1300139 1300139 $ sysctl vfs.zfs.vdev.trim_on_init sysctl: unknown oid 'vfs.zfs.vdev.trim_on_init' $ ---- Background: <https://forums.freebsd.org/threads/83731/> someone trying to make sense of ZFS. My initial guess: the chapter needs a review in the context of OpenZFS.
Not the FreeBSD Handbook alone … Manual pages ============ <https://www.freebsd.org/cgi/man.cgi?query=zfs&sektion=4&manpath=FreeBSD> * finds nothing for zfs(4) in FreeBSD 13.0. Compare with OpenZFS <https://openzfs.github.io/openzfs-docs/man/4/zfs.4.html>: > zfs — tuning of the ZFS kernel module For zfs(4) in ports <https://www.freebsd.org/cgi/man.cgi?query=zfs&sektion=4&manpath=FreeBSD-Ports> – more specifically, <https://www.freebsd.org/cgi/man.cgi?query=zfs&sektion=4&manpath=FreeBSD+Ports+13.0> in 'FreeBSD ports r13.0' – we have, for example: > zfs_arc_max=0B (ulong) There's a corresponding entry in the OpenZFS page for zfs(4). Actual tunables =============== FreeBSD 13.0-RELEASE includes this variable: vfs.zfs.arc.max – the value of which defaults to: 0 The name of the variable in FreeBSD is comparable to the name of the parameter/variable in original OpenZFS documentation. Fair enough. FreeBSD Handbook ================ <https://docs.freebsd.org/en/books/handbook/book/#zfs-advanced-tuning-arc_max> describes this variable, with a different name, which probably predates OpenZFS in FreeBSD: vfs.zfs.arc_max No mention of 0 and there's this: > … all RAM but 1 GB, or 5/8 of all RAM, whichever is more. > Use a lower value if … The word "but" is not ideal ("minus" would be better); and the reader might wonder: Lower than what?
(In reply to Graham Perrin from comment #1) Please ignore the apparent reference to something twenty-seven years old in Subversion. It's quite unlike what I truly wrote; an effect of bug 261686 bugging FreeBSD Bugzilla itself.
Frequently Asked Questions for FreeBSD 12.X and 13.X From <https://docs.freebsd.org/en/books/faq/#zfs-ssd-trim>: > ZFS TRIM support was added to FreeBSD 10-CURRENT … > vfs.zfs.trim.enabled=0 This is not applicable to 14.0-CURRENT; assume that it's also not applicable to 13.0-RELEASE. root@mowa219-gjp4-8570p-freebsd:~ # sysctl vfs.zfs.trim.enabled=0 sysctl: unknown oid 'vfs.zfs.trim.enabled' root@mowa219-gjp4-8570p-freebsd:~ # uname -KU 1400053 1400053 root@mowa219-gjp4-8570p-freebsd:~ #
From <https://forums.freebsd.org/posts/558971>: > … tunable is a noun; "… basically a special type of sysctl that > gets its initial value from the kernel environment (set by loader)". 'Tuning' <https://docs.freebsd.org/en/books/handbook/zfs/#zfs-advanced-tuning> (currently 20.6.1) lists some tunables. 'Loader Tunables' <https://docs.freebsd.org/en/books/handbook/zfs/#_loader_tunables> (currently 20.6.2.3) begins: > Increases the kmem address space on all FreeBSD architectures. … As a beginning, that's potentially misleading. The subsection heading can be, more simply: 'Tunables'. If it's truly on all FreeBSD architectures, then why is it under an i386 heading?
Jonathan Vasquez asked (bug 265424 comment 2): > … Is it a backwards compatibility reason? … vfs.zfs.arc_max and vfs.zfs.arc_min are legacy in the context of OpenZFS. <https://github.com/openzfs/zfs/commit/0421f257b20f41e33fb69e067b47beed2c5bd3bd> | <https://github.com/freebsd/freebsd-src/commit/0421f257b20f41e33fb69e067b47beed2c5bd3bd>
(In reply to Graham Perrin from comment #5) freqlabs@ please, do you know, should parameters such as these two exist in OpenZFS in FreeBSD? For consistency, using . in lieu of _: vfs.zfs.arc.free_target vfs.zfs.arc.no_grow_shift ---- % sysctl vfs.zfs.arc_free_target vfs.zfs.arc_free_target: 86343 % sysctl vfs.zfs.arc_no_grow_shift vfs.zfs.arc_no_grow_shift: 5 % sysctl vfs.zfs.arc.free_target sysctl: unknown oid 'vfs.zfs.arc.free_target' % sysctl vfs.zfs.arc.no_grow_shift sysctl: unknown oid 'vfs.zfs.arc.no_grow_shift' % sysctl vfs.zfs | sort | less % date ; freebsd-version ; uname -KU Sat 6 Aug 2022 08:31:42 BST 14.0-CURRENT 1400064 1400064 % <https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Module%20Parameters.html#zfs-module-parameters>
(In reply to Graham Perrin from comment #6) They should exist but currently don't. They are only tunables on FreeBSD so weren't forced into the new structure when we merged with the ZFS on Linux tree and never got redone. I'll add it to my TODO list.
(In reply to Ryan Moeller from comment #7) Until they come back, are there any OpenZFS equivalents for 13.x users? Asking so we can document how to keep that tuning or an equivalent meanwhile.
(In reply to Pau Amma from comment #8) Yes the alternative is to use the existing sysctl names. What's missing is new names for the sysctls under vfs.zfs.arc instead of vfs.zfs directly. https://github.com/openzfs/zfs/pull/13756
(In reply to Ryan Moeller from comment #9) Those present in the OpenZFS version imported in 13.0, you mean?+++++++++++++++++++++++++++++++++++++
(In reply to Pau Amma from comment #10) Sorry, faulty keyboard.
(In reply to Pau Amma from comment #10) vfs.zfs.arc_free_target vfs.zfs.arc_no_grow_shift These currently have the same names in 13 as they did in 12.
(In reply to Ryan Moeller from comment #12) Thanks.
I'll take this bug report, as a formality, since I became a (doc) committer in June, however please note: * it's way too much for me. We need proactive input from people and groups with _good_ knowledge of: * ZFS in stable/12 * OpenZFS in FreeBSD 13.0-RELEASE and greater * OpenZFS in general. Thanks. Today's D37512 for FAQ needs review, should be simple enough. I'm not slaving over it, because there'll be a complete overhaul of FAQ in due course. <https://wiki.freebsd.org/Myths#ZFS_will_use_too_much_memory> around three weeks ago was partly wrong, and has been discussed in #storage in Discord for FreeBSD. I'm not sure how to correct it. For now, I might simply remove what's wrong.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/doc/commit/?id=d89e8fd3d40df804a7057b8371221477d1f5b3de commit d89e8fd3d40df804a7057b8371221477d1f5b3de Author: Graham Perrin <grahamperrin@FreeBSD.org> AuthorDate: 2022-12-03 09:39:47 +0000 Commit: Graham Perrin <grahamperrin@FreeBSD.org> CommitDate: 2022-12-03 09:39:47 +0000 FAQ: TRIM: GELI, ZFS, OpenZFS: pruning, tidiness The ViewVC views of 2013 Subersion revisions are no longer of interest. vfs.zfs.trim.enabled is unknown in FreeBSD 13.1-RELEASE-p3. Questions about TRIM in the context of GELI are not frequently asked. Also, non-contentious grammar, punctuation, and formatting: * surrounding apostrophes ('…') are obviously missing from some quotes * missing full stops (.) * trailing white space * AsciiDoc line breaks * et cetera, there might remain a superfluous break, such things can be addressed as a fix to this commit. This commit reduces, but does not fix, bug report 261212: > Update the ZFS chapter (20) of the FreeBSD Handbook, and other > OpenZFS-related pages PR: 261212 Reviewed by: mav, pauamma Approved by: delphij (doc) Differential revision: https://reviews.freebsd.org/D37512 documentation/content/en/books/faq/_index.adoc | 166 ++++++++++++++++--------- 1 file changed, 108 insertions(+), 58 deletions(-)
For OpenZFS in FreeBSD 13.0-RELEASE and greater, we already benefit from the authoritative point of reference: OpenZFS Documentation <https://openzfs.github.io/openzfs-docs/> 12.4-RELEASE is expected to reach its end of life one year from now <https://www.freebsd.org/security/#sup>. I'm not inclined to put great effort into documenting the ways in which its ZFS differs from OpenZFS in superior versions of the operating system. ---- Refocusing on OpenZFS, the preamble at <https://github.com/freebsd/freebsd-doc/blob/main/documentation/content/en/books/handbook/zfs/_index.adoc#the-z-file-system-zfs> includes this: > … A complete list of features and terminology is in > ZFS Features and Terminology. For starters, let's remove that paragraph and the linked subsection …
Triage, batch edit (just one): * for twenty-eight FreeBSD Handbook-related reports that had gained a personal assignee, prior group/list assignee doc@ was missing from the CC list. Gentle hint: <https://wiki.freebsd.org/Bugzilla/> ▶ do, don't …
<http://markmail.org/message/rgcwur3lz3npo77b> identifies a mistake under <https://github.com/freebsd/freebsd-doc/blob/main/documentation/content/en/books/handbook/zfs/_index.adoc#412-deduplication>.
<https://docs.freebsd.org/en/books/handbook/zfs/#zfs-advanced-tuning> Two of the list items mention: vfs.zfs.arc.meta_limit This no longer exists, % sysctl -d vfs.zfs.arc.meta_limit sysctl: unknown oid 'vfs.zfs.arc.meta_limit' % uname -KU 1500000 1500000 % Bug 271003 comment 2 draws attention to merged pull request 14359. Related: <https://github.com/openzfs/zfs/commit/009d3288dea524c7ad373b04b65bee8bb6f0bfea> > Tag 2.2.0-rc1 · openzfs/zfs@009d328 – with features including: > - Fully adaptive ARC eviction (#14359)
Created attachment 245208 [details] Log of PDF made from /usr/doc/documentation <https://docs.freebsd.org/en/books/handbook/book/#zfs-term> <https://github.com/freebsd/freebsd-doc/blob/main/documentation/content/en/books/handbook/zfs/_index.adoc#8-zfs-features-and-terminology> > ZFS Features and Terminology From the attached file: > table cell content that exceeds the height of a single page
Created attachment 245211 [details] Screenshot of PDF pages 528–533 (In reply to Graham Perrin from comment #20) For the cell to work: the warning and information texts, currently boxed (screenshot attached), might be better elsewhere. More generally: * compare with the OpenZFS-provided list of supported vdevs, <https://openzfs.github.io/openzfs-docs/man/master/7/zpoolconcepts.7.html#Virtual_Devices_(vdevs)> * if FreeBSD-provided advice (e.g. partitioning) will vary from the OpenZFS recommendation to use a whole disk (not a partition), then the variation should be explained.