On Sat, Aug 30, 2025 at 7:11 PM Tomoaki AOKI <junch...@dec.sakura.ne.jp> wrote:
> On Sat, 30 Aug 2025 16:45:15 -0700 > "Mel P." <list_free...@bluerosetech.com> wrote: > > > On 2025-08-30 16:34, Tomoaki AOKI wrote: > > > On Fri, 29 Aug 2025 07:49:49 -0600 > > > Warner Losh <i...@bsdimp.com> wrote: > > > > > >> On Fri, Aug 29, 2025, 7:12 AM Tomoaki AOKI <junch...@dec.sakura.ne.jp > > > > >> wrote: > > >> > > >> This is why I previously commented with git hash and/or n number. > > >>> > > >> > > >> This is harder and introduces a git dependency to the loader process. > The > > >> kernel has this, true. And hg, svn, gitup and a few others. It's a > mess > > >> that I'd rather not have since the loader is built a dozen times, not > once > > >> like the kernel, and any slowdown when one of the above scms > misbehaves is > > >> greater. > > >> > > >> Warner > > > > > > Yeah, precisely determining what read-incompatible features is/are > > > enabled (whitelisted) is the key point for the bootcodes / loaders. > > > > > > Using date/time, ancient method was (IIRC) the date/time the bootcodes > > > / loaders are "built", NOT "committed to master repo". > > > > > > Obtaining the actually wanted date / time needs git functionality > > > in current form, thus, heavy-weighted for bootcodes / loaders. > > > > Just have it store the whitelist in a retrievable format. Provide the > > information directly. > > The whitelist would be this. > > https://cgit.freebsd.org/src/tree/stand/libsa/zfs/zfsimpl.c#n109 > > Note that it includes only read-incompatible features supported. > So seeing this alone could confuse like "Isn't feature xxx supported? > Should I re-create pool without the (read-compatible) feature xxx?!". > > The comment in the file is clear enough for me, but what about for > someone just started learning about ZFS? > > To know features including read-compatible ones that are "enabled" > by default ("active" is another thing), we need to understand > in what state the whole ZFS codes are when the bootcode / loader > is built. And this require to specify the commit the build is > done at. > > Warner, please correct me if I'm mis-understanding. > I believe you're the best person who knows correctly in loader area. Generally, that's correct. Many new features are 'read-only' stable. Meaning, if they are enabled, then the on-media format isn't affected, so read-only applications like the boot loader can read them effectively. Most new features are like this, and none of these new ZFS features needs a new loader... The problem comes when there's new features that aren't exactly 'read-only-stable' but which the bootloader can none-the-less read. These features are added with a much slower rate, and it's not always clear if a feature falls into this category or not. The latest one being the feature that allows one to expand a ZRAID. There's some on-media implications for that, but it's not clear if the loader should allow it or not. So far, we've come down on the side of 'not' and recommend you don't enable it for your root dataset. The boot loader reading routines would need code to properly read a zraid dataset that's being expanded in case the kernel or klds (or whatever) lands in the area that matters (I don't recall all the details, but while things are rebalancing for the dataset, the striping is variable and the boot code would need to know that, but currently does not). So FreeBSD's _FreeBSD_version changes on the order of weekly. We get, on main, about 30-80 changes a year over the recent history of FreeBSD. This is why I said that the main FreeBSD version is a good 'ticker' to see if the boot loader you have likely will boot the BE with different bells and whistles enabled. The rate that there's new features that aren't read-only-stable that the loader can none-the-less read is on the order of once or thrice a year (though there was a period just after we adopted OpenZFS this was much faster, since OpenZFS was catching up on the built-up backlog of features to integrate). This suggests to me that even if we don't bump OpenZFS on each import (which happens about monthly), we'll still be able to use it FreeBSD version to know if a given Zpool can be booted. I'm not sure about having a full database for this. It strikes me as rather overkill. However, it would be nice, perhaps, if we had a list of features and FreeBSD versions that bectl (and zpool upgrade maybe) could add some (possibly optional, unsure on that point) safety that says 'Hold on, that upgrade with that boot loader is trouble! Watch yourself!' or something. Sadly, I'm already multiply overbooked... Warner P.S. I'm sure I got the names pedantically incorrect... 'read incompatible' is more correct, for example... Fixing this after the fact is too hard in firefox since gmail on this chromebook is super slow to edit, but not bad for writing...
