Re: Branching for netbsd-10 next week

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Thu, 8 Dec 2022 20:21:26 +0100
    From:        Martin Husemann <martin%duskware.de@localhost>
    Message-ID:  <20221208192126.GB343%mail.duskware.de@localhost>


  | Now the question: should the default install really use this new FFS type,
  | or should it default to plain FFSv2?

I'd suggest FFSv2, but that's not much more than a suggestion.

  |  - unaware users may install FFSv2ea file systems and later find the need
  |    to access them from older NetBSD kernels. "Downgrading" them is
  |    quite easy using the ufs2ea-flip tool mentioned in the wiki page,
  |    but it is not "plug & play".

I thought that tool was intended to take old (as in what existed at the
start of this year in HEAD) FFSv2 files with EAs and convert them into
FFSv2ea filesystems?

Downgrading necessarily loses the EA data, and ought to be accomplished
by simply changing the filesystem type (on a clean filesystem) and running
fsck -fy   -- the loss of data makes that an unattractive thing to suggest.

I wonder if we could perhaps have FFSv2pea filesystems (p==potential) - that
is one which allows creation of EAs, automatically switches itself to FFSv2ea
if an EA is created (and then just stays that way without specific action),
but is otherwise identical to an FFSv2 filesystem (so much so that one can
be downgraded by simply flipping the magic number and doing nothing else) ?
fsck could treat those exactly like FFSv2, plus verifying the EA inode fields
contain nothing.

  |  - if FFSv2ea is not the default, most new installs will create non-EA
  |    enabled file systems and 
  |     - the EAs will not get much testing

That one is an issue, so I'd probably leave it like it is, probably with
a warning in the initial motd, when -10 is branched, for those who want to
get started on -10 early (beta testers, who may be expected to understand
things a bit better), and in HEAD, but switch 10 back just before it is
actually released.

  |     - packets from pkgsrc (like samba) will continue to have the
  |	  corresponding options disabled by default

Those packages could have warnings in DESCR and MESSAGE (or whatever it
is called) advising of the need for FFSv2ea for full functionality.
How does samba (and anything else like it) deal with this - if it is
a compile time option, then since NetBSD supports EAs (and hence the
sys call interface exists) EA support in samba should be enabled.
More likely it is to be a run time problem, as whether a filesys has
EA support or not will vary, some might, others not, so whether samba
can provide EA functionality will tend to vary file by file (or at least
directory by directory) - given that, a solid warning that FFSv2ea support
is needed in the samba man page (or other doc) for NetBSD should allow
users to know what to do.

  |     - users will have a hard time to find the conversion options later.

If that's correct, then we need better doc.   Perhaps an entry in a
FAQ "How do I enable extended attributes" and "How to I export a filesystem
to FreeBSD/linux/..."

kre