linux-kernel - [LSF TOPIC] statx extensions for subvol/snapshot filesystems & more

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <2uvhm6gweyl7iyyp2xpfryvcu2g3padagaeqcbiavjyiis6prl@yjm725bizncq>
Date: Tue, 20 Feb 2024 19:51:05 -0500
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: linux-bcachefs@...r.kernel.org, linux-btrfs@...r.kernel.org, 
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org, lsf-pc@...ts.linux-foundation.org
Subject: [LSF TOPIC] statx extensions for subvol/snapshot filesystems & more

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