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

[Demi Marie Obenour <demiobenour@gmail.com>]

On 12/11/24 8:38 AM, Theodore Ts'o wrote:
> 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.

I’m not too worried about this, and instead am of the opinion that it
needs to be fixed on the blkid side (by ignoring the ZFS superblock).

>>>> /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/

It’s the other way around: the GPT only provides the mountpoint,
never the type.  That’s why I filed an issue [1] asking for
per-filesystem-type UUIDs.

[1]: https://github.com/uapi-group/specifications/issues/132

> 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.

Thanks for confirming what I expected.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)