On Tue, Dec 12, 2023 at 11:59:51AM +1100, NeilBrown wrote: > On Tue, 12 Dec 2023, Kent Overstreet wrote: > > NFSv4 specs that for the maximum size? That is pretty hefty... > > It is - but it needs room to identify the filesystem and it needs to be > stable across time. That need is more than a local filesystem needs. > > NFSv2 allowed 32 bytes which is enough for a 16 byte filesys uuid, 8 > byte inum and 8byte generation num. But only just. > > NFSv3 allowed 64 bytes which was likely plenty for (nearly?) every > situation. > > NFSv4 doubled it again because .... who knows. "why not" I guess. > Linux nfsd typically uses 20 or 28 bytes plus whatever the filesystem > wants. (28 when the export point is not the root of the filesystem). > I suspect this always fits within an NFSv3 handle except when > re-exporting an NFS filesystem. NFS re-export is an interesting case... Now I'm really curious - i_generation wasn't enough? Are we including filesystem UUIDs? I suppose if we want to be able to round trip this stuff we do need to allocate space for it, even if a local filesystem would never include it. > I suggest: > > STATX_ATTR_INUM_NOT_UNIQUE - it is possible that two files have the > same inode number > > > __u64 stx_vol Volume identifier. Two files with same stx_vol and > stx_ino MUST be the same. Exact meaning of volumes > is filesys-specific NFS reexport that you mentioned previously makes it seem like this guarantee is impossible to provide in general (so I'd leave it out entirely, it's just something for people to trip over). But we definitely want stx_vol in there. Another thing that people ask for is a way to ask "is this a subvolume root?" - we should make sure that's clearly specified, or can we just include a bit for it? > STATX_VOL Want stx_vol > > __u8 stx_handle_len Length of stx_handle if present > __u8 stx_handle[128] Unique stable identifier for this file. Will > NEVER be reused for a different file. > This appears AFTER __statx_pad2, beyond > the current 'struct statx'. > STATX_HANDLE Want stx_handle_len and stx_handle. Buffer for > receiving statx info has at least > sizeof(struct statx)+128 bytes. > > I think both the handle and the vol can be useful. > NFS can provide stx_handle but not stx_vol. It is the thing > to use for equality testing, but it is only needed if > STATX_ATTR_INUM_NOT_UNIQUE is set. > stx_vol is useful for "du -x" or maybe "du --one-volume" or similar. > > > Note that we *could* add stx_vol to NFSv4.2. It is designed for > incremental extension. I suspect we wouldn't want to rush into this, > but to wait to see if different volume-capable filesystems have other > details of volumes that are common and can usefully be exported by statx Sounds reasonable
