Re: Immutable vs read-only for Windows compatibility

["Darrick J. Wong" <djwong@kernel.org>]

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.
>