Received-SPF: pass (google.com: domain of linux-kernel+bounces-73882-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Tue, 20 Feb 2024 19:51:05 -0500
From: Kent Overstreet <kent.overstreet@linux.dev>
To: linux-bcachefs@vger.kernel.org, linux-btrfs@vger.kernel.org, 
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, lsf-pc@lists.linux-foundation.org
Subject: [LSF TOPIC] statx extensions for subvol/snapshot filesystems & more
Message-ID: <2uvhm6gweyl7iyyp2xpfryvcu2g3padagaeqcbiavjyiis6prl@yjm725bizncq>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Recently we had a pretty long discussion on statx extensions, which
eventually got a bit offtopic but nevertheless hashed out all the major
issues.

To summarize:
 - guaranteeing inode number uniqueness is becoming increasingly
   infeasible, we need a bit to tell userspace "inode number is not
   unique, use filehandle instead"
 - we need a new field (st_vol, volume ID) for subvolumes - subvolumes
   aren't filesystems and st_dev is problematic too
 - I'd like a bit for flagging subvolume roots, as well

That's basic stuff. Beyond that, it would be useful to standardize APIs
for
 - recursively enumerating subvolumes (without walking full fs
   heirarchy), and translating from volume IDs to paths
 - exposing snapshot tree structure - which is yet another tree
   structure we need to expose, completely unrelated to normal fs path
   tree structure
 - snapshot recovery - i.e. atomically replacing one subvolume with
   another subvolume that was a snapshot
 - setting default subvolume root
 - exposing disk usage of snapshots

& probably more.

Hoping to get some real participation from the btrfs crew - if they
could talk about what they've done and what else they see a need for,
that would be wonderful. Additionally, we tend to not have a lot of
userspace people at LSF, but standardizing and improving these APIs is
something userspace would _very_ much like us to do, so in addition to
the usual crew I'm hoping to bring Neal Gompa to share that perspective.

Cheers,
Kent