Re: Ensuring that mount(8) will always interpret a filesystem correctly

"Theodore Ts'o" <[email protected]>
Newsgroups org.kernel.vger.util-linux
Message-ID <[email protected]>
On Tue, Dec 10, 2024 at 06:28:28PM -0500, Demi Marie Obenour wrote:
> >> Was https://github.com/util-linux/util-linux/issues/1305 a
> >> collision between ZFS and ext4?
> > 
> > Yes, but in this case, ZFS was incorrectly detected. As you can see
> > from the bug report, blkid ended with an "ambiguous result" error.

mke2fs (mkfs.ext4) does attempt to zero the typical locations where
conflicting superblocks might be found.  The ext4 metadata is located
at the beginning of the file system, except for the first 1k, which we
leave zero out on all platforms except for Sparc (the exact reason is
lost in the midsts of time, since it pre-exists git, but as I recall
Sparc had something critical that would cause its BIOS to lose its
marbles if we zeroed it out), and we also zero out the very end of the
disk where the MD superblock is located.

It sounds like ZFS is putting its superblock someplace random that
mke2fs ext4 doesn't know about.  If someone wants to do the research
to let me know what needs to be zeroed out to zap the ZFS superblock,
please feel to file a bug against e2fsck (or better yet, send me a
patch :-P ) and I'll be happy to add support for it.

> >> /etc/fstab provides an explicit filesystem type.  The Discoverable
> >> Partition Specification doesn't.

From what I can tell, the Discoverable Partition Table specification,
at least as defined here[1] only supports explicit file system types
supplied by the GPT partition table.

[1] https://uapi-group.org/specifications/specs/discoverable_partitions_specification/

My personal preference is this *is* the best way to do things; the
main reason why we have blkid is because of the disaster which is the
MSDOS FAT partition table, where there was only a single byte used for
the partition type, that (a) was largely ignored by other x86
operating systems, and (b) wasn't under our control, so we couldn't
define a new partition type each time we introduced a new Linux file
system.

In general, having explicit file system types, whether it is in
/etc/fstab, or in the GPT partition table, is the better way to go.
Using blkid is ideally the fallback when the best possible way doesn't
work, since it will ultimately always be a "best efforts" sort of
thing.

That being said, I suspect that if you ask, file system maintainers
will be happy to try to make things work better --- just send us a
patch or tell us what we need to do.  ZFS is not a native Linux file
system, and blkid pre-dates ZFS, so it's not something that I bothered
testing.  It doesn't help that I had absolutely zero interest in
dealing with Sun deliberately making the CDDL incompatible with the
GPL, and Larry Elison potentially trying to sue us into the ground.  :-)

Cheers,

						- Ted
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.