On Fri, Mar 25, 2022 at 04:42:27PM +0000, Trond Myklebust wrote: > On Fri, 2022-03-25 at 07:31 +1100, Dave Chinner wrote: > > > and anyway the point of a > > > hierarchical namespace is to be able to list nodes on each level. > > > We > > > can use getxattr() for this purpose, just like getvalues() does in > > > the > > > above example. > > > > Yup, and like Casey suggests, you could implement a generic > > getvalues()-like user library on top of it so users don't even need > > to know where and how the values are located or retrieved. > > > > The other advantage of an xattr interface is that is also provides a > > symmetrical API for -changing- values. No need for some special > > configfs or configfd thingy for setting parameters - just change the > > value of the parameter or mount option with a simple setxattr call. > > That retains the simplicity of proc and sysfs attributes in that you > > can change them just by writing a new value to the file.... > > The downsides are, however, that the current interface provides little > in the way of atomicity if you want to read or write to multiple > attributes at the same time. Something like a backup program might want > to be able to atomically retrieve the ctime when it is backing up the > attributes. I assumed that batched updates were implied and understood after my earlier comments about XFS_IOC_ATTRMULTI_BY_HANDLE as used by xfsdump/restore for the past 20+ years. > Also, when setting attributes, I'd like to avoid multiple syscalls when > I'm changing multiple related attributes. > > IOW: Adding a batching interface that is akin to what Miklos was > proposing would be a helpful change if we want to go down this path. Yup, that's exactly what XFS_IOC_ATTRMULTI_BY_HANDLE provides and I'm assuming that would also be provided by whatever formalised generic syscall API we come up with here... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
