On 14.12.2021 22:00, Mark Millard wrote: > On 2021-Dec-14, at 17:35, Alexander Motin <m...@freebsd.org> wrote: > >> On 14.12.2021 20:21, Mark Millard wrote: >>> I presume that because of FreeBSD's releng/13.0 and stable/13 (and >>> releng/13.? futures) that: >>> >>> /usr/share/zfs/compatibility.d/openzfs-2.1-freebsd >>> >>> will never have edonr added to the file. Sound right? >> >> FreeBSD stable/13 is tracking still alive upstream zfs-2.1-release >> branch. It is still updated periodically, but primarily with bug fixes. > > I infer from the above that: > > /usr/share/zfs/compatibility.d/openzfs-2.1-freebsd > > is unlikely to be changed to be inaccurate relative to releng/13.0 , at > least as long as 13.0 is a supported FreeBSD release, but probably for > all the releng/13.? .
Yes, that would be my personal assumption. >>> Is there going to be a /usr/share/zfs/compatibility.d/openzfs-2.*-freebsd* >>> that has edonr as well (instead of using a openzfs-2.1-linux file for >>> such)? If yes, when does the file show up? Does main get drafts of the >>> file over time until there is a releng/14.0 that would have the final >>> version? >> >> FreeBSD main though tracks openzfs master branch, and as a moving target >> it has no compatibility definitions. I'd expect by the time of FreeBSD >> stable/14 branching there to be some new openzfs branch it could switch >> to, but so far AFAIK there were no specific announcements yet. And >> enabled edonr is a step toward not differentiating FreeBSD and Linux >> compatibility settings any more. > > I infer from the above that it will be much closer to releng/14.0 's > time frame before there will be an additional: > > /usr/share/zfs/compatibility.d/openzfs-*-freebsd* > > ( or a name that does not even mention freebsd or linux but > applies to releng/14.0 ). Good to know. Right. There would be nothing bad to have more openzfs releases before stable/14 branching though, just not after. We'll need to coordinate that with upstream. -- Alexander Motin
