Message-ID: <20250117185947.ylums2dhmo3j6hol@pali>
Date: Fri, 17 Jan 2025 19:59:47 +0100
From: Pali Rohár <pali@...nel.org>
To: Amir Goldstein <amir73il@...il.com>
Cc: "Darrick J. Wong" <djwong@...nel.org>,
	ronnie sahlberg <ronniesahlberg@...il.com>,
	Chuck Lever <chuck.lever@...cle.com>,
	Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>,
	linux-fsdevel@...r.kernel.org, linux-cifs@...r.kernel.org,
	linux-kernel@...r.kernel.org, Steve French <sfrench@...ba.org>,
	Alexander Viro <viro@...iv.linux.org.uk>
Subject: Re: Immutable vs read-only for Windows compatibility

On Friday 17 January 2025 19:46:30 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.

Yes, you understood it correctly. I was asking for standardizing API how
to get/set these attributes from userspace. And Chuck wrote that would
like to have also standardized it for kernel consumers like nfsd or
ksmbd. Which makes sense.

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

Userspace fileserver, like Samba, would just use that standardized
userspace API for get/set attributes. And in-kernel fileservers like
nfsd or ksmbd would like to use that API too.

And there were some proposals how filesystems without native
support for these attributes could store and preserve these attributes.
So this can be a confusion in this email thread discussion.

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

So you would also benefit from standardizing of API for these attributes
as then you could implement that API for xfs.

Powered by blists - more mailing lists