On Fri, Jan 17, 2025 at 07:46:30PM +0100, Amir Goldstein wrote: > > > Looking at the FILE_ATTRIBUTE_* flags defined in SMB protocol > > > (fs/smb/common/smb2pdu.h) I wonder how many of them will be > > > needed for applications beyond the obvious ones that were listed. > > > > Well they only asked for seven of them. ;) > > > > I chatted with Ted about this yesterday, and ... some of the attributes > > (like read only) imply that you'd want the linux server to enforce no > > writing to the file; some like archive seem a little superfluous since > > on linux you can compare cmtime from the backup against what's in the > > file now; and still others (like hidden/system) might just be some dorky > > thing that could be hidden in some xattr because a unix filesystem won't > > care. > > > > And then there are other attrs like "integrity stream" where someone > > with more experience with windows would have to tell me if fsverity > > provides sufficient behaviors or not. > > > > But maybe we should start by plumbing one of those bits in? I guess the > > gross part is that implies an ondisk inode format change or (gross) > > xattr lookups in the open path. > > > > I may be wrong, but I think there is a confusion in this thread. > I don't think that Pali was looking for filesystems to implement > storing those attributes. I read his email as a request to standardize > a user API to get/set those attributes for the filesystems that > already support them and possibly for vfs to enforce some of them > (e.g. READONLY) in generic code. > > Nevertheless, I understand the confusion because I know there > is also demand for storing those attributes by file servers in a > standard way and for vfs to respect those attributes on the host. > > Full disclosure - I have an out of tree xfs patch that implements > ioctls XFS_IOC_[GS]ETDOSATTRAT and stashes these > attributes in the unused di_dmevmask space. [cc linux-xfs] Urrrrk, please don't fork the xfs ondisk format! --D > Compared to the smb server alternative of storing those attributes > as xattrs on the server, this saves a *lot* of IO in an SMB file browsing > workload, where most of the inodes have large (ACL) xattrs that do > not fit into the inode, because SMB protocol needs to return > those attributes in a response to READDIR(PLUSPLUS), so > it needs to read all the external xattr blocks. > > So yeh, I would love to have proper support in xfs... > > Thanks, > Amir. >