Re: [LSF/MM/BPF TOPIC] statx attributes

From: Amir Goldstein <amir73il@gmail.com>
To: Steve French <smfrench@gmail.com>
Cc: lsf-pc <lsf-pc@lists.linux-foundation.org>,
	CIFS <linux-cifs@vger.kernel.org>,
	 samba-technical <samba-technical@lists.samba.org>,
	 linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Jan Kara <jack@suse.cz>,  Christian Brauner <brauner@kernel.org>,
	Kent Overstreet <kent.overstreet@linux.dev>,
	 David Howells <dhowells@redhat.com>
Subject: Re: [LSF/MM/BPF TOPIC] statx attributes
Date: Thu, 7 Mar 2024 10:54:27 +0200	[thread overview]
Message-ID: <CAOQ4uxg8YbaYVU1ns5BMtbW8b0Wd8_k=eFWj7o36SkZ5Lokhpg@mail.gmail.com> (raw)
In-Reply-To: <CAH2r5mutAn2G3eC7yRByF5YeCMokzo=Br0AdVRrre0AqRRmTEQ@mail.gmail.com>

On Thu, Mar 7, 2024 at 7:36 AM Steve French <smfrench@gmail.com> wrote:
>
> Following up on a discussion a few years ago about missing STATX
> attributes, I noticed a case recently where some tools on other OS
> have an option to skip offline files (e.g. the Windows equivalent of
> grep, "findstr", and some Mac tools also seem to do this).
>

Which API is used in other OS to query the offline bit?
Do they use SMB specific API, as Windows does?

> This reminded me that there are a few additional STATX attribute flags
> that could be helpful beyond the 8 that are currently defined (e.g.
> STATX_ATTR_COMPRESSED, STATX_ATTR_ENCRYPTED, STATX_ATTR_NO_DUMP,
> STATX_ATTR_VERITY) and that it be worthwhile revisiting which
> additional STATX attribute flags would be most useful.

I agree that it would be interesting to talk about new STATX_ attributes,
but it should already be covered by this talk:
https://lore.kernel.org/linux-fsdevel/2uvhm6gweyl7iyyp2xpfryvcu2g3padagaeqcbiavjyiis6prl@yjm725bizncq/

We have a recent example of what I see as a good process of
introducing new STATX_ attributes:
https://lore.kernel.org/linux-fsdevel/20240302220203.623614-1-kent.overstreet@linux.dev/
1. Kent needed stx_subvol_id for bcachefs, so he proposed a patch
2. The minimum required bikeshedding on the name ;)
3. Buy in by at least one other filesystem (btrfs)

w.r.t attributes that only serve one filesystem, certainly a requirement from
general purpose userspace tools will go a long way to help when introducing
new attributes such as STATX_ATTR_OFFLINE, so if you get userspace
projects to request this functionality I think you should be good to go.

>
> "offline" could be helpful for fuse and cifs.ko and probably multiple
> fs to be able to report,

I am not sure why you think that "offline" will be useful to fuse?
Is there any other network fs that already has the concept of "offline"
attribute?

> but there are likely other examples that could help various filesystems.

Maybe interesting for network fs that are integrated with fscache/netfs?
It may be useful for netfs to be able to raise the STATX_ATTR_OFFLINE
attribute for a certain cached file in some scenarios?

As a developer of HSM API [1], where files on any fs could have an
"offline" status,
STATX_ATTR_OFFLINE is interesting to me, but only if local disk fs
will map it to
persistent inode flags.

When I get to it, I may pick a victim local fs and write a patch for it.

Thanks,
Amir.

[1] https://github.com/amir73il/fsnotify-utils/wiki/Hierarchical-Storage-Management-API