On Sat, 30 Aug 2025 21:10:46 -0600 Warner Losh <i...@bsdimp.com> wrote:
> 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... Thanks! It would be nice if files in https://cgit.freebsd.org/src/tree/sys/contrib/openzfs/cmd/zpool/compatibility.d/ installed at /usr/share/zfs/compatibility.d have sufficient info, but unfortunately, it's not... Not grouped as read compatible / read incompatible. Not having the data which FreeBSD version started supporting the specific features in single and fixed name file. Regards. -- Tomoaki AOKI <junch...@dec.sakura.ne.jp>
