Re: Using the upcoming fsinfo()

[Karel Zak <kzak@redhat.com>]

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

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

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com