Re: File system corruption due to UFS2 extended attributes

[Chuck Silvers <chuq%chuq.com@localhost>]

On Tue, May 24, 2022 at 07:51:08AM -0400, Greg Troxel wrote:
> 
> Chuck Silvers <chuq%chuq.com@localhost> writes:
> 
> > The introduction in NetBSD's implementation of UFS2 of the extended
> > attribute code from FreeBSD has introduced a compatibility problem
> > with previous releases of NetBSD.  The explanation of this problem is
> > a bit involved and requires knowing some history, so please bear with me
> > as I explain.
> 
> Your analysis and approach make sense to me, even though it's
> regrettable that it is necessary.  I guess UFS needs zfs-style feature
> flags....
> 
> What about compatibility with FreeBSD?
> 
>   - What happens if someone takes a FreeBSD UFS2 filesystem and mounts
>     it under NetBSD 9?

FreeBSD UFS2 and NetBSD 9 UFS2 are "somewhat" compatible, the main exceptions
being extended attributes and the interpretation of some of the fs_flags bits
in the superblock.  These fs_flags bits that are used different between
the two control enablement of various optional features, such as
"check hashes" in FreeBSD, and wapbl and "quota2" in NetBSD.
Note that FreeBSD's bit for "check hashes" and NetBSD's bit for "quota2"
are the same bit, so if this bit is set by one OS then the other OS
will do the wrong thing.  FreeBSD would decide that everything in
the NetBSD fs is corrupt because none of the check hashes matches.
NetBSD will refuse to mount a FreeBSD fs read/write because other quota2
information is missing or wrong (this one I know from recent experience).

Similarly, the bits for FreeBSD "NFS4 ACLs" and NetBSD "wapbl" are the same.

FreeBSD only clears some unknown fs_flags bits, whereas NetBSD clears
all unknown fs_flags bits.

Looking again now, I see that various of the newer superblock fields are
also different.  These fields were added by reusing some of the various
"spare" bytes that were available, but often the same "spare" bytes were
reused for different purposes by each OS.  I'm sure the different
interpretations of some of these newer fields can cause trouble,
however sometimes nothing obviously bad happens when a file system
created on one OS is used on the other OS.

It all depends on exactly what you do.


>   - What happens if someone tries to mount a NetBSD <=9 UFS2 filesystem
>     on FreeBSD?   A 10 UFS2 filesystem w/o ea?  with?

NetBSD <=9 UFS2 vs FreeBSD UFS2 is described above.
NetBSD 10 UFS2 (non-ea) will be the same as NetBSD <=9 UFS2
after the changes that I am proposing now.
NetBSD 10 UFS2ea will not be recognized at all by FreeBSD (or by NetBSD <=9).


> Or is it already the case that FreeBSD and NetBSD do not interoperate
> with UFS2?

They will each try to operate on the other's UFS2 file systems
(because they can't tell the difference), but there is a good chance
that data loss will result if you mount read/write from the other OS.


> And same questions for the other active BSD variants, which I think is
> mostly OpenBSD and Dragonfly these days but I have lost track.

OpenBSD UFS2 appears to be the same as NetBSD <=9 with respect to
extended attributes (extattrs are not supported).  OpenBSD's treatment
of fs_flags is different as well, only two fs_flags bits are recognized
and unknown flags are not cleared.  At least one superblock field
is different too.

Dragonfly does not support UFS2 at all.

-Chuck