On Tue, Jan 14, 2025 at 04:44:55PM -0500, Chuck Lever wrote: > On 1/14/25 4:10 PM, Pali Rohár wrote: > > > My thought was to have a consistent API to access these attributes, and > > > let the filesystem implementers decide how they want to store them. The > > > Linux implementation of ntfs, for example, probably wants to store these > > > on disk in a way that is compatible with the Windows implementation of > > > NTFS. > > > > > > A common API would mean that consumers (like NFSD) wouldn't have to know > > > those details. > > > > > > > > > -- > > > Chuck Lever > > > > So, what about introducing new xattrs for every attribute with this pattern? > > > > system.attr.readonly > > system.attr.hidden > > system.attr.system > > system.attr.archive > > system.attr.temporary > > system.attr.offline > > system.attr.not_content_indexed "attr" is a poor choice for an attribute class (yes, naming is hard...). It's a windows file attribute class, the name should reflect that. However, my main problem with this approach is that it will be pretty nasty in terms of performance regressions. xattr lookup is *much* more expensive than reading a field out of the inode itself. If you want an example of the cost of how a single xattr per file can affect the performance of CIFS servers, go run dbench (a CIFS workload simulator) with and without xattrs. The difference in performance storing a single xattr per file is pretty stark, and it only gets worse as we add more xattrs. i.e. xattrs like this will have significant performance implications for all file create, lookup/stat and unlink operations. IOWs, If this information is going to be stored as an xattr, it needs to be a single xattr with a well defined bit field as it's value (i.e. one bit per attribute). The VFS inode can then cache that bitfield with minimal addition overhead during the first lookup/creation/modification for the purpose of fast, low overhead, statx() operation. > Yes, all of them could be stored as xattrs for file systems that do > not already support these attributes. > > But I think we don't want to expose them directly to users, however. > Some file systems, like NTFS, might want to store these on-disk in a way > that is compatible with Windows. > > So I think we want to create statx APIs for consumers like user space > and knfsd, who do not care to know the specifics of how this information > is stored by each file system. > > The xattrs would be for file systems that do not already have a way to > represent this information in their on-disk format. Even the filesystems that store this information natively should support the xattr interface - they just return the native information in the xattr format, and then every application has a common way to change these attributes. (i.e. change the xattr to modify the attributes, statx to efficiently sample them. -Dave. -- Dave Chinner david@xxxxxxxxxxxxx
