On Wednesday 15 January 2025 09:42:26 ronnie sahlberg wrote: > 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. Sure. This was just to show how pattern can look like. Does not have to be the final name. I agree that naming is hard, but in this case I think the harder part would be to design API. Btw, first 4 attributes were inherited from dos, so they are not originally from windows. But that is not important and it is better to have consistent naming. > > 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. Exactly, thank you for better explanation. If filesystem supports "hidden" attribute then request from userspace call (setxattr system.attr.hidden) would be translated to filesystem native "hidden" attribute. Which for SMB2+ is SetInfo(), for NFS4 is op_setattr(hidden), for FAT/exFAT/NTFS is updating hidden bit in attrbit field, for UDF is updating hidden bit in FileCharacteristics. And for other filesystem which supports "hidden" attribute natively, it would be stored as that xattr system.attr.hidden as is. Performance for sure needs to checked. I have already wrote it that it could be a problem for userspace applications when they would need to call lot of syscall to just list directory entries with all attributes. So for getting attributes maybe some statx() interface could be useful. In my opinion, applications would probably ask for attributes more times than trying to set or change them. It is like stat() which is used more times than utimes() (or other syscalls for changing stat stuff). In any case, Linux SMB client is already fetching all those attributes because basically SMB protocol always sends them. So SMB communication between client and server should not be affected at all by any solution which is going to be chosen. > > > > > 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 > >
