Re: Using the upcoming fsinfo()

[Ian Kent <raven@themaw.net>]

On Wed, 2019-05-22 at 15:55 +0200, Karel Zak wrote:
> On Wed, May 22, 2019 at 09:14:37PM +0800, Ian Kent wrote:
> > On Tue, 2019-05-21 at 21:28 -0700, L A Walsh wrote:
> > > On 2019/05/21 19:59, Ian Kent wrote:
> > > > I hadn't planned on producing a utility but I do have code that I've
> > > > been using to learn how to use the call.
> > > > 
> > > > I could turn that into a utility for use from scripts at some point.
> > > >   
> > > 
> > > ---
> > >      not required, but thought it might allow for more types of
> > > tests/usages.
> > > If it is really of limited or no benefit, I'm not gonna lose sleep.
> > > > Avoiding having to parse string output (from the proc file system
> > > > mount tables) is one of the key reasons to use a system call for
> > > > this.
> > > > 
> > > > So this isn't the point of doing it.
> > > >   
> > > 
> > > I get that....this wasn't intended as an 'endpoint' just a way for those
> > > not
> > > implementing and using the calls to get a feel for the call.  It may
> > > not serve
> > > a useful purpose in this case, but some system calls have direct
> > > user-utils that
> > > are very useful.  The lack of a system util to manipulate the pty calls
> > > forced
> > > me to write a few-line 'C' prog just to make 1 call to approve
> > > something.  Eventually switched to a more robust interface in perl.
> > 
> > We will see, I will end up with something that's more or less example
> > usage anyway.
> 
> I'd like to write something like "mountsh" one day. The idea is to
> have very low-level tool that is able to provide command line
> interface to the all fragments of the new mount API in the same
> granularity as provided by kernel (mount(8) is too high-level in this
> case).

There's fairly simple example usage of several of the mount-api
calls in samples/vfs/test-fsmount.c.

There's the in kernel mount-api documentation at
Documentation/filesystems/mount_api.txt although that's more
oriented to usage within the kerenl.

I was wondering if kernel file systems that have not been converted
to use the new api (but use the legacy mount-api kernel code) will
work properly with the new mount-api? I think they would have to
for the mount-api to be viable but I'm not sure.

LOL, I remember, all those years ago, when you set out to write
libmount and I wanted to convert autofs to use it.

Sadly I got swamped with other work and ended up more concerned
about eliminating proc mount table usage wherever possible in
autofs but with the fsinfo() and mpount-api changes I should be
able to change autofs to use libmount.

After all these years I'll finally be able to get meaningful
error codes that I simply can't get from mount(8) or mount.nfs(8).

The autofs kernel module has been capable of passing these back to
user space for years now and there shouldn't be too many autofs
user space changes needed.

But there's a lot of work to be done on libmount and we absolutely
must keep libmount stable all the way so it's a big challenge.

> 
> Anyway, the primary goal is to use the new syscalls on standard
> places (e.g. libmount) where it improves performance.
> 
> > > I.e. why not subdirs for 'by-mountpoint', or by-device, or
> > > whole-dev-vs.partition, or by UUID....like some things are listed
> > > in /dev.  That would allow you to narrow in on the mount you want for
> > > doing whatever.
> > 
> > TBH, I can't see that amount of code being added to the VFS
> > for this.
> > 
> > Simple annoyances like some mounts won't have a UUID, or won't
> > have partition devices associated with them will also cause
> > inconsistent views of the mounts.
> 
> or more filesystems mounted on the same mountpoint, mountpoint is
> deleted, etc...
> 
>     Karel
>