Re: File system corruption due to UFS2 extended attributes

[David Holland <dholland-tech%netbsd.org@localhost>]

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
dholland%netbsd.org@localhost