On Wed, 15 Jan 2025 at 09:32, Dave Chinner <david@xxxxxxxxxxxxx> wrote: > > 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. For this use case I don't think he means to store them on the cifs server as xattr (or case-insensitive extended attributes as cifs does). They can already be read/written using SMB2 GetInfo/SetInfo commands. What I think he means is to read these attributes using SMB2 GetInfo but then present this to the application via a synthetic xattr. Application reads a magic xattr and then the driver just makes it up based on other information it has. (cifs does this for other things already afaik) Correct me if I am wrong Pali, but you mean translate the SMB2 attribute field into a magic xattr? But that means it is not storage of the attributes anymore but rather the API for applications to read these attributes. > > > 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 >
