public inbox for linux-api@vger.kernel.org
 help / color / mirror / Atom feed
From: Christian Brauner <brauner@kernel.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: Jan Kara <jack@suse.cz>, Aleksa Sarai <cyphar@cyphar.com>,
	 Alexander Viro <viro@zeniv.linux.org.uk>,
	Chuck Lever <chuck.lever@oracle.com>,
	 Jeff Layton <jlayton@kernel.org>,
	Amir Goldstein <amir73il@gmail.com>,
	 Alexander Aring <alex.aring@gmail.com>,
	linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org,
	 linux-kernel@vger.kernel.org, linux-api@vger.kernel.org
Subject: Re: [PATCH RFC v2] fhandle: expose u64 mount id to name_to_handle_at(2)
Date: Tue, 28 May 2024 10:20:21 +0200	[thread overview]
Message-ID: <20240528-wachdienst-weitreichend-42f8121bf764@brauner> (raw)
In-Reply-To: <ZlSzotIrVPGrC6vt@infradead.org>

> Well, how about we fix the thing for real:
> 
>  - allow file systems to provide a uniqueu identifier of at least
>    uuid size (16 bytes) in the superblock or through an export operation
>  - for non-persistent file systems allow to generate one at boot time
>    using the normal uuid generation helpers
>  - add a new flag to name_to_handle_at/open_by_handle_at to include it
>    in the file handle, and thus make the file handle work more like
>    the normal file handle
>  - add code to nfsd to directly make use of this
> 
> This would solve all the problems in this proposal as well as all the
> obvious ones it doesn't solve.

As I've said multiple times on the thread I agree that this is what we
should do next and I would be happy to take patches for this. But
exposing the 64bit mount id doesn't impede or complicate that work. It's
a simple and useful addition that can be done now and doesn't prevent us
from doing the proposed work.

Hell, if you twist my arm I'll even write the patches for this.

  reply	other threads:[~2024-05-28  8:20 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-23 20:57 [PATCH RFC v2] fhandle: expose u64 mount id to name_to_handle_at(2) Aleksa Sarai
2024-05-24  4:58 ` Amir Goldstein
2024-05-26  9:25 ` Christoph Hellwig
2024-05-26 19:01   ` Aleksa Sarai
2024-05-27 11:47     ` Christoph Hellwig
2024-05-27 12:29       ` Christian Brauner
2024-05-27 13:17         ` Christian Brauner
2024-05-27 15:47           ` Trond Myklebust
2024-05-28  7:05             ` Christian Brauner
2024-05-27 16:18         ` Christoph Hellwig
2024-05-27 13:34       ` Jan Kara
2024-05-27 16:24         ` Christoph Hellwig
2024-05-28  8:20           ` Christian Brauner [this message]
2024-05-28  8:28             ` Christoph Hellwig
2024-05-28  9:17               ` Christian Brauner
2024-05-28 10:55                 ` Christoph Hellwig
2024-05-28 12:04                   ` Christian Brauner
2024-05-28 13:22                     ` Christoph Hellwig
2024-05-28 13:28                       ` Miklos Szeredi
2024-05-29  6:34                         ` Christoph Hellwig
2024-06-01  8:12                         ` Aleksa Sarai
2024-06-03 10:30                           ` Jan Kara
2024-06-04  5:22                           ` Christoph Hellwig
2024-05-29  7:40                       ` Christian Brauner
2024-05-31  8:14                         ` Christoph Hellwig
2024-05-31 10:28                           ` Christian Brauner
2024-05-26 22:32   ` Trond Myklebust
2024-05-27 11:49     ` hch
2024-05-27 15:38       ` Trond Myklebust
2024-05-27 16:29         ` hch
2024-05-28  7:12           ` Christian Brauner
2024-05-28  7:15             ` hch
2024-05-28 10:11           ` Jan Kara
2024-05-28 10:56             ` hch
2024-05-28 23:25               ` Dave Chinner
2024-05-29  6:24                 ` hch
2024-05-29  7:23                   ` Amir Goldstein
2024-05-27 12:22   ` Christian Brauner

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=20240528-wachdienst-weitreichend-42f8121bf764@brauner \
    --to=brauner@kernel.org \
    --cc=alex.aring@gmail.com \
    --cc=amir73il@gmail.com \
    --cc=chuck.lever@oracle.com \
    --cc=cyphar@cyphar.com \
    --cc=hch@infradead.org \
    --cc=jack@suse.cz \
    --cc=jlayton@kernel.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /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