From: Christoph Hellwig <hch@infradead.org>
To: Anand Jain <anajain.sg@gmail.com>
Cc: Theodore Tso <tytso@mit.edu>,
Christoph Hellwig <hch@infradead.org>,
"Darrick J. Wong" <djwong@kernel.org>,
linux-ext4@vger.kernel.org, linux-btrfs@vger.kernel.org,
linux-xfs@vger.kernel.org, Anand Jain <asj@kernel.org>,
dsterba@suse.com
Subject: Re: [PATCH v2 3/3] ext4: derive f_fsid from block device to avoid collisions
Date: Fri, 17 Apr 2026 00:34:40 -0700 [thread overview]
Message-ID: <aeHikJwRmFdDg5FW@infradead.org> (raw)
In-Reply-To: <b593ab17-afaf-4128-97eb-0ab9c23dec5c@gmail.com>
On Thu, Apr 16, 2026 at 11:21:41PM +0800, Anand Jain wrote:
> > But given that you originally stumbled across this with Overlayfs,
> > because it was originally using s_uuid, and that didn't work well for
> > btrfs, why not change overlayfs to just use s_uuid plus kdev_t in its
> > xattr, and just fix the problem for overlayfs? That has the benefit
> > that it will work for all file system types in Linux, not just for
> > those where we have changed what f_fsid does.
>
> Using `kdev_t` (or any derivation of it) for persistent storage, such
> as Overlayfs xattrs, is problematic. Since `kdev_t` is transient and
> inconsistent across reboots or device re-discovery, it could lead to
> broken associations.
Yes, using a dev_t in anything persistent is a really bad ida.
> It seems we've reached the functional limits of f_fsid.
> If we want to solve this properly for Overlayfs, NFS handles, or a
> complex system monitoring..etc, we need a new identifier let's call
> it f_fsid_v2, that meets the following requirements:
>
> System-wide Uniqueness: Must distinguish between cloned filesystems.
>
> Persistence: Must remain consistent across reboots/HW re-enumeration.
>
> Non-On-Disk: Must not be stored on-disk.
The third requirement doesn't make much sense to me. If it is
persistent it. or something it can be derived from must be stored
on-disk.
>
>
> One possible implementation for f_fsid_v2 could be:
>
> f_fsid_v2 = hash(s_uuid, block_device_serial, [subvol_id])
>
> For pseudo block devices (virtio-blk, loop, nbd, brd,..),
> the serial could be derived recursively:
>
> serial_number = hash(backing_file.f_fsid_v2, backing_file.ino)
What i the point in this? All of this seems to be better served
by s_uuid.
> Note on Hardware Serials:
> Standard storage protocols (T10, NVMe, SAS) mandate unique,
> persistent serials per LUN. While I've seen T10 protocol
> violations during my time authoring Solaris HBA drivers, I
> believe these outliers shouldn't dictate the design.
No, T10 does not actually mandate unique identifiers, NVMe does, but the
implementations are often totally broken.
next prev parent reply other threads:[~2026-04-17 7:34 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-21 11:55 [PATCH v2 0/3] fix s_uuid and f_fsid consistency for cloned filesystems Anand Jain
2026-03-21 11:55 ` [PATCH v2 1/3] btrfs: use on-disk uuid for s_uuid in temp_fsid mounts Anand Jain
2026-03-21 11:55 ` [PATCH v2 2/3] btrfs: derive f_fsid from on-disk fsuuid and dev_t Anand Jain
2026-03-21 11:55 ` [PATCH v2 3/3] ext4: derive f_fsid from block device to avoid collisions Anand Jain
2026-03-23 4:16 ` Theodore Tso
2026-03-23 15:29 ` Darrick J. Wong
2026-03-23 16:44 ` Darrick J. Wong
2026-03-25 10:02 ` Andreas Dilger
2026-03-25 10:59 ` Anand Jain
2026-03-25 12:59 ` Theodore Tso
2026-04-02 7:33 ` Anand Jain
2026-03-23 15:41 ` Anand Jain
2026-04-04 8:59 ` Anand Jain
2026-04-07 5:22 ` Christoph Hellwig
2026-04-07 14:47 ` Theodore Tso
2026-04-08 22:28 ` Anand Jain
2026-04-09 4:10 ` Theodore Tso
2026-04-09 9:45 ` Anand Jain
2026-04-09 13:12 ` Theodore Tso
2026-04-16 15:21 ` Anand Jain
2026-04-17 7:34 ` Christoph Hellwig [this message]
2026-04-22 11:39 ` Anand Jain
2026-04-23 5:08 ` Christoph Hellwig
2026-04-27 10:16 ` Anand Jain
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=aeHikJwRmFdDg5FW@infradead.org \
--to=hch@infradead.org \
--cc=anajain.sg@gmail.com \
--cc=asj@kernel.org \
--cc=djwong@kernel.org \
--cc=dsterba@suse.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=tytso@mit.edu \
/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.