linux-api.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Mateusz Guzik <mjguzik@gmail.com>
Cc: Florian Weimer <fweimer@redhat.com>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-api@vger.kernel.org, Dave Chinner <dchinner@redhat.com>
Subject: Re: Testing if two open descriptors refer to the same inode
Date: Mon, 29 Jul 2024 09:36:01 -0400	[thread overview]
Message-ID: <20240729133601.GA557749@mit.edu> (raw)
In-Reply-To: <ghqndyn4x7ujxvybbwet5vxiahus4zey6nkfsv6he3d4en6ehu@bq5s23lstzor>

On Mon, Jul 29, 2024 at 12:18:15PM +0200, Mateusz Guzik wrote:
> 
> Are you claiming on-disk inode numbers are not guaranteed unique per
> filesystem? It sounds like utter breakage, with capital 'f'.

The reality is that there exists file systems which do not return
unique inode numbers.  For example, there are virtiofs implementations
which pass the inode numbers straight through with a fixed dev_t.  If
you have a large number of packages mounted via iscsi, and those
packages include shared libraries, then you can have two different
shared libraries with the same inode number, and then you can watch
the dynamic liunker get Very Confused, and debugging the problem can
be.... interesting.  (Three gueses how I found out about this, and the
first two don't count.  Yes, we figured out a workaround.)

So that breakage exists already, today.

For people who don't like this, they can stick to those file systems
that still guarantee unique inode numbers, at least for local disk
file systems --- for example, to use ext4 and xfs, over btrfs and
bcachefs.

However, this is a short-term expedient, and in the long term, we will
need to guide userspace to use something that is more likely to work,
such as file handles.  And ideally, this needs to be standardized at
venues such as the Austin Group, so that it becomes interfaces which
are used across operating systems, not just for Linux.  It's going to
be a multi-year, if not decade-long, effort...

						- Ted

  parent reply	other threads:[~2024-07-29 13:36 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-29  6:55 Testing if two open descriptors refer to the same inode Florian Weimer
2024-07-29  9:09 ` Aleksa Sarai
2024-07-29  9:29   ` Florian Weimer
2024-07-29 10:18 ` Mateusz Guzik
2024-07-29 10:40   ` Florian Weimer
2024-07-29 10:50     ` Mateusz Guzik
2024-07-29 10:56       ` Mateusz Guzik
2024-07-29 10:57       ` Florian Weimer
2024-07-29 11:06         ` Mateusz Guzik
2024-07-29 11:36           ` Florian Weimer
2024-07-29 12:00             ` Mateusz Guzik
2024-07-29 11:40           ` Aleksa Sarai
2024-07-31 18:07             ` David Sterba
2024-07-29 11:47           ` Aleksa Sarai
2024-07-29 12:12             ` Mateusz Guzik
2024-07-29 23:19               ` Dave Chinner
2024-07-29 23:08         ` Dave Chinner
2024-07-29 12:26   ` Christian Brauner
2024-07-29 13:36   ` Theodore Ts'o [this message]
2024-07-30  2:31     ` Dave Chinner
2024-07-30  4:19       ` Theodore Ts'o
2024-07-30 15:38       ` Christoph Hellwig
2024-07-29 15:24 ` Jeff Layton
2024-07-29 15:39   ` Florian Weimer

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=20240729133601.GA557749@mit.edu \
    --to=tytso@mit.edu \
    --cc=dchinner@redhat.com \
    --cc=fweimer@redhat.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mjguzik@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).