From: "Theodore Ts'o" <tytso@mit.edu>
To: Demi Marie Obenour <demiobenour@gmail.com>
Cc: Karel Zak <kzak@redhat.com>, util-linux@vger.kernel.org
Subject: Re: Ensuring that mount(8) will always interpret a filesystem correctly
Date: Wed, 11 Dec 2024 08:38:08 -0500 [thread overview]
Message-ID: <20241211133808.GB1912640@mit.edu> (raw)
In-Reply-To: <155cef10-48b4-42f0-bacf-b9e1d7394206@gmail.com>
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
next prev parent reply other threads:[~2024-12-11 13:38 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-08 1:45 Ensuring that mount(8) will always interpret a filesystem correctly Demi Marie Obenour
2024-12-09 10:26 ` Karel Zak
2024-12-10 5:11 ` Demi Marie Obenour
2024-12-10 11:16 ` Karel Zak
2024-12-10 23:28 ` Demi Marie Obenour
2024-12-11 13:38 ` Theodore Ts'o [this message]
2024-12-14 22:08 ` Demi Marie Obenour
2024-12-15 3:20 ` Theodore Ts'o
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241211133808.GB1912640@mit.edu \
--to=tytso@mit.edu \
--cc=demiobenour@gmail.com \
--cc=kzak@redhat.com \
--cc=util-linux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.