[LSF/MM/BPF TOPIC] finishing up mount API conversions; consistency & logging

[LSF/MM/BPF TOPIC] finishing up mount API conversions; consistency & logging

[Eric Sandeen]

In case this is of interest to anyone I'll propose it.

The "new" mount API was merged about 5 years ago, but not all filesystems
were converted, so we still have the legacy helpers in place. There has been
a slow trickle of conversions, with a renewed interest in completing this
task.

The remaining conversions are of varying complexity (bcachefs might
be "fun!") but other questions remain around how userspace expects to use
the informational messages the API provides, what types of messages those
should be, and whether those messages should also go to the kernel dmesg.
Last I checked, userspace is not yet doing anything with those messages,
so any inconsistencies probably aren't yet apparent.

There's also the remaining task of getting the man pages completed.

There were also some recent questions and suggestions about how to handle
unknown mount options, see Miklos' FSOPEN_REJECT_UNKNOWN suggestion. [1]

I'm not sure if this warrants a full session, as it's actually quite
an old topic. If nothing else, a BOF for those interested might be
worthwhile.

Thanks,
-Eric

[1] https://lore.kernel.org/linux-fsdevel/CAJfpeguCKgMPBbD_ESD+Voxq5ChS9nGQFdYrA4+YWBz17yFADA@mail.gmail.com/

Re: [LSF/MM/BPF TOPIC] finishing up mount API conversions; consistency & logging

[Amir Goldstein]

On Mon, Apr 15, 2024 at 6:59 PM Eric Sandeen <sandeen@redhat.com> wrote:
>
> In case this is of interest to anyone I'll propose it.
>
> The "new" mount API was merged about 5 years ago, but not all filesystems
> were converted, so we still have the legacy helpers in place. There has been
> a slow trickle of conversions, with a renewed interest in completing this
> task.
>
> The remaining conversions are of varying complexity (bcachefs might
> be "fun!") but other questions remain around how userspace expects to use
> the informational messages the API provides, what types of messages those
> should be, and whether those messages should also go to the kernel dmesg.
> Last I checked, userspace is not yet doing anything with those messages,
> so any inconsistencies probably aren't yet apparent.
>
> There's also the remaining task of getting the man pages completed.
>
> There were also some recent questions and suggestions about how to handle
> unknown mount options, see Miklos' FSOPEN_REJECT_UNKNOWN suggestion. [1]
>
> I'm not sure if this warrants a full session, as it's actually quite
> an old topic. If nothing else, a BOF for those interested might be
> worthwhile.
>

Christian,

I scheduled a slot for your talk on "Mount API extensions" on Tue 11:30
before Eric's Mount API conversions session.

Do you think this is the right order or do you prefer these sessions
to be swapped?

Also, this seems like a large topic, so I could try to clear more than
30min in the
schedule for it if you like. the buffer_heads session after your talks
will probably
be removed from there anyway.

I was thinking that we need a followup session for statmount/listmount [1]
What's still missing (mount change notifications, fsinfo) and what are
the next steps.
Are you planning to address those in your session?

Thanks,
Amir.

[1] https://lore.kernel.org/linux-fsdevel/20240105-vfs-mount-5e94596bd1d1@brauner/

Re: [LSF/MM/BPF TOPIC] finishing up mount API conversions; consistency & logging

[Christian Brauner]

On Wed, May 08, 2024 at 01:32:10PM +0300, Amir Goldstein wrote:
> On Mon, Apr 15, 2024 at 6:59 PM Eric Sandeen <sandeen@redhat.com> wrote:
> >
> > In case this is of interest to anyone I'll propose it.
> >
> > The "new" mount API was merged about 5 years ago, but not all filesystems
> > were converted, so we still have the legacy helpers in place. There has been
> > a slow trickle of conversions, with a renewed interest in completing this
> > task.
> >
> > The remaining conversions are of varying complexity (bcachefs might
> > be "fun!") but other questions remain around how userspace expects to use
> > the informational messages the API provides, what types of messages those
> > should be, and whether those messages should also go to the kernel dmesg.
> > Last I checked, userspace is not yet doing anything with those messages,
> > so any inconsistencies probably aren't yet apparent.
> >
> > There's also the remaining task of getting the man pages completed.
> >
> > There were also some recent questions and suggestions about how to handle
> > unknown mount options, see Miklos' FSOPEN_REJECT_UNKNOWN suggestion. [1]
> >
> > I'm not sure if this warrants a full session, as it's actually quite
> > an old topic. If nothing else, a BOF for those interested might be
> > worthwhile.
> >
> 
> Christian,
> 
> I scheduled a slot for your talk on "Mount API extensions" on Tue 11:30
> before Eric's Mount API conversions session.
> 
> Do you think this is the right order or do you prefer these sessions
> to be swapped?
> 
> Also, this seems like a large topic, so I could try to clear more than
> 30min in the
> schedule for it if you like. the buffer_heads session after your talks
> will probably
> be removed from there anyway.
> 
> I was thinking that we need a followup session for statmount/listmount [1]
> What's still missing (mount change notifications, fsinfo) and what are
> the next steps.
> Are you planning to address those in your session?

Yeah, let's do that in my session. The order is fine by me!