On 12/5/23 23:01, NeilBrown wrote: > On Wed, 06 Dec 2023, Donald Buczek wrote: > >> statx() would be very nice, because you can avoid additional system >> calls. I wish, we could get the file_handle in the same call, but I >> assume that is not possible to be added to statx() because of the >> potential big and unknown length. However, I assume the combination >> of volume-ident and inode number, which both would be available from >> one statx() call, are also unique, so this should do, too. >
> The file handle is limited in size to 128 bytes. The current statx > structure doesn't have that much spare space, but I don't see a problem > with having it return a larger structure if that is explicitly > requested. Of course I don't know what other developers might think of > that. > > Extending statx to return a "root-of-subvol" flag or possibly a > "subvol-id" u64 should be uncontroversial and would allow backup tools > and similar to easily ignore subvols. This would need to be driven the > the bcachefs team of course. I'd vote for the subvol-id. I think, with bcachefs a u32 would do, but it could be return as u64 for future growth or other filesystems. 128 additional bytes for the space for (any) filehandle seems like a lot. And it is more than the current 96 bytes reserve of `struct statx`. I don't know if a user-provided pointer field (optional, to another 128 bytes user buffer) would be considerable at all. It's not really needed for bcachefs (its file_handle is just 16 byte anyway: u64 inode, u32 volume, u32 generation) or for my usecase (don't blindly walk into snapshots). But other tools might profit from the ability to get any file_handle with statx(), e.g. userspace nfs server, software with some an external file registration database. Best Donald > > Thanks, > NeilBrown -- Donald Buczek [email protected] Tel: +49 30 8413 1433
