[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6czkpcm4gxcjik3drcy6eys6lannfk55oowdesem2qr3gfgobw@lblo3vzck43e>
Date: Fri, 8 Mar 2024 12:13:17 -0500
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: "Darrick J. Wong" <djwong@...nel.org>
Cc: Neal Gompa <neal@...pa.dev>, linux-fsdevel@...r.kernel.org,
linux-bcachefs@...r.kernel.org, linux-btrfs@...r.kernel.org, linux-kernel@...r.kernel.org,
Josef Bacik <josef@...icpanda.com>, Miklos Szeredi <mszeredi@...hat.com>,
Christian Brauner <brauner@...nel.org>, David Howells <dhowells@...hat.com>
Subject: Re: [PATCH v2] statx: stx_subvol
On Fri, Mar 08, 2024 at 08:56:33AM -0800, Darrick J. Wong wrote:
> On Fri, Mar 08, 2024 at 11:48:31AM -0500, Kent Overstreet wrote:
> > It's a new feature, not a bugfix, this should never get backported. And
> > I the bcachefs maintainer wrote the patch, and I'm submitting it to the
> > VFS maintainer, so if it's fine with him it's fine with me.
>
> But then how am I supposed to bikeshed the structure of the V2 patchset
> by immediately asking you to recombine the patches and spit out a V3?
>
> </sarcasm>
>
> But, seriously, can you update the manpage too?
yeah, where's that at?
> Is stx_subvol a u64
> cookie where userspace mustn't try to read anything into its contents?
> Just like st_ino and st_dev are (supposed) to be?
Actually, that's up for debate. I'm considering having the readdir()
equivalent for walking subvolumes return subvolume IDs, and then there'd
be a separate call to open by ID.
Al's idea was to return open fds to child subvolumes, then userspace can
get the path from /proc; that's also a possibility.
The key thing is that with subvolumes it's actually possible to do an
open_by_id() call with correct security checks on pathwalking - because
we don't have hardlinks so there's no ambiguity.
Or we might do it getdents() style and return the path directly.
But I think userspace is going to want to work with the volume
identifiers directly, which is partly why I'm considering why other
options might be cleaner.
Another thing to consider: where we're going with this is giving
userspace a good efficient interrface for recursive tree traversal of
subvolumes, but it might not be a bad idea to do that for mountpoints as
well - similar problems, similar scalability issues that we might want
to solve eventually.
> Should the XFS data and rt volumes be reported with different stx_vol
> values?
Maybe?
Powered by blists - more mailing lists