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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Dec 14, 2024 at 05:08:54PM -0500, Demi Marie Obenour wrote:
> > 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.

Bleah, you're right.  Other partition tables, including MBR(!) used
the "partiton type" to be the kind of file system.  (For example,
0x07h meant OS/2, 0x09 meant QNX/Coherent/OS-9, 0x0Bh meant FAT32 with
CHS addressing, 0x0Ch meat FAT32 with LBA, 39h meant Plan9, etc.)

When I saw "partition type" in the UEFI spec, I thought they were
seeing the path of wisdom and moving away from in-band signaling to an
explicit type specification --- but you're right, looking at the UEFI
spec more closely, it's about how the file system is to be used, not
the file system type.

(It's really not even the mount point, since
773f91ef-66d4-49b5-bd83-d683bf40ad16 means "per-user home partition",
but since the UUID doesn't specify the username, you would't know
whether it was supposed to be mounted in /home/lucy, or /home/snoopy,
or /home/charlie_brown.  Yelch....)

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

I disagree; blkid's *job* is to detect the file system type, and just
ignoring all ZFS superblocks means that it won't be able to detect ZFS
file systems, which would be sad.  And having some kind of arbitrary
preference where blkid were to say, "well, if it's ambiguous whether a
block device is ext4 or btrfs or ZFS, I'll just arbitrarily say ext4
because I like ext4 more" is well, arbitrary.

The best way to solve this is to either have users use "wipefs -a
/dev/hdXX" before running a mkfs program, but in the spirit of being
kind to users[1] who don't know about wipefs, or for distro installers
that don't bother to call wipefs, I'm perfectly happy to teach
mkfs.ext4 how to make the right thing happen automatically.  I just
need to know how to zap ZFS superbloks.

BTW, in practice this happens automatically for SSD's, since we will
call BLKDISCARD on the entire device, for better FTL GC performance.
But for HDD's, we will need to explicitly write zeroes in the correct
location.

Cheers,

					- Ted

[1] Using a variation from Struck and White's "The Elements of Style"
where they said, "always write with a deep empathy towards the
reader", we should strive to program with deep empathy towards the
user.  :-)





[Index of Archives]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux