On Mon, May 23, 2022 at 09:47:37PM -0700, Chuck Silvers wrote: > So what can we do about this? There aren't any really great > options. But the only change which will guarantee that all old > NetBSD releases (which do not know about extend attributes) will > not corrupt file system images where extended attributes have been > stored is to create a new variant of UFS2 with a different magic > number (the "fs_magic" field in the superblock). This is what I > propose to do. I spoke with Kirk McKusick about this problem and > he agreed that creating a new UFS2 variant with a different magic > number is the best way to deal with this situation.
On the minus side, this means all FreeBSD volumes (which do know about extended attributes) will be treated as NetBSD 9 volumes (which don't). There probably isn't any way around this, and it isn't the first time this has happened, including for UFS1 (e.g. the wapbl bit), so maybe we just ought to have our own format going forwards, since this: : /* : * NOTE: COORDINATE ON-DISK FORMAT CHANGES WITH THE FREEBSD PROJECT. : */ repeatedly hasn't worked. But in that case the names of options and whatnot should be set up accordingly and the default should be our format. We did a migration like this with partition types years ago and AFAICR it wasn't perfect but wasn't a trainwreck either. also, a quibble: > - fsck will take a new option "-c ea" to specify that an existing UFS2 > file system should be converted to support extended attributes > (ie. converted to UFS2ea). The migration code really belongs in tunefs rather than fsck. :-| -- David A. Holland [email protected]
