On Tue, Dec 12, 2023 at 01:13:07PM +1100, NeilBrown wrote: > On Tue, 12 Dec 2023, Kent Overstreet wrote: > > 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). > > NFS would not set stx_vol and would not return STATX_VOL in stx_mask. > So it would not attempt to provide that guarantee. > > Maybe we don't need to explicitly make this guarantee. I tend to lean towards pushing people to only use the filehandle for testing if files are the same, and discouraging using stx_vol for this purpose. Since the filehandle will include the generation number, it lets us fix permenantly time of use races that stx_vol would still be subject to. > > 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? > > The start way to test for a filesystem root - or mount point at least - > is to stat the directory in question and its parent (..) and see if the > have the same st_dev or not. > Applying the same logic to volumes means that a single stx_vol number is > sufficient. > > I'm not strongly against a STATX_ATTR_VOL_ROOT flag providing everyone > agrees what it means that we cannot imagine any awkward corner-cases > (like a 'root' being different from a 'mount point'). I'd like to do that, it lets us define properly some corner cases (is the filesystem also a subvolume root if it's got the same volume ID as the parent dir, on another filesystem? Let's make sure that's a yes).
