Re: Immutable vs read-only for Windows compatibility

[ronnie sahlberg <ronniesahlberg@gmail.com>]

On Wed, 15 Jan 2025 at 09:32, Dave Chinner <david@fromorbit.com> 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@fromorbit.com
>