All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bruce Dubbs <bruce.dubbs@gmail.com>
To: Karel Zak <kzak@redhat.com>, Ian Kent <raven@themaw.net>
Cc: util-linux@vger.kernel.org
Subject: Re: Using the upcoming fsinfo()
Date: Mon, 13 May 2019 11:04:50 -0500	[thread overview]
Message-ID: <75f27b68-52ff-7f6b-b031-0637ba04df2f@gmail.com> (raw)
In-Reply-To: <20190513090823.2qys6sv4tspbr3b2@ws.net.home>

On 5/13/19 4:08 AM, Karel Zak wrote:
> On Mon, May 13, 2019 at 01:33:22PM +0800, Ian Kent wrote:
>> Some of you may know that David Howells is working on getting
>> a new system call fsinfo() merged into the Linux kernel.
>>
>> This system call will provide access to information about mounted
>> mounts without having to read and parse file based mount tables
>> such as /proc/self/mountinfo, etc.
>>
>> Essentially all mounts have an id and one can get the id of a
>> mount by it's path and then use that to obtain a large range
>> of information about it.
>>
>> The information can include a list of mounts within the mount
>> which can be used to traverse a tree of mounts or the id used
>> to lookup information on an individual mount without the need
>> to traverse a file based mount table.
>>
>> I'd like to update libmount to use the fsinfo() system call
>> because I believe using file based methods to get mount
>> information introduces significant overhead that can be
>> avoided.
>>
>> Because the fsinfo() system call provides a very different way
>> to get information
>> about mounts, and having looked at the current
>> code, I'm wondering what will be
>> the best way to go about it.
>>
>> Any suggestions about the way this could best be done, given
>> that the existing methods must still work, will be very much
>> appreciated.
> 
> It would be nice to start with some low-level things to read info
> about a target (mountpoint) into libmnt_fs, something like:
> 
>      int mnt_fsinfo_fill_fs(chat char *tgt, struct libmnt_fs *fs)
> 
> and fill create a complete mount table by fsinfo():
> 
>      int mnt_fsinfo_fill_table(struct libmnt_table *tab)
> 
> ... probably add fsinfo.c to code to keep it all together.
> 
> So, after then we can use these functions in our code.
> 
> The nice place where is ugly overhead with the current mountinfo is
> context_umount.c code, see lookup_umount_fs() and
> mnt_context_find_umount_fs(). In this code we have mountpoint and we
> need more information about it (due to redirection to umount.<type>
> helpers, userspace mount options, etc.). It sounds like ideal to use
> mnt_fsinfo_fill_fs() if possible.
> 
> The most visible change will be to use mnt_fsinfo_fill_table() with in
> mnt_table_parse_file() if the file name is "/proc/self/mountinfo".
> This will be huge improvement as we use this function in systemd on
> each mount table change...
> 
> The question is how easily will be to replace mountinfo with fsinfo().

I may be stating the obvious, but this proposal does not appear to 
simplify anything because it is kernel version dependent.  From what I 
understand, the new and old methods will both need to be supported for 
quite some time.

I'm not suggesting that the changes not be made, but I suggest going slow.

   -- Bruce

  reply	other threads:[~2019-05-13 16:04 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-13  5:33 Using the upcoming fsinfo() Ian Kent
2019-05-13  9:08 ` Karel Zak
2019-05-13 16:04   ` Bruce Dubbs [this message]
2019-05-14  0:04     ` Ian Kent
2019-05-15 11:27     ` Karel Zak
2019-05-14  0:23   ` Ian Kent
2019-05-15 11:45     ` Karel Zak
2019-05-16  0:13       ` Ian Kent
2019-05-21 19:21         ` L A Walsh
2019-05-22  2:59           ` Ian Kent
2019-05-22  3:12             ` Ian Kent
2019-05-22  4:28             ` L A Walsh
2019-05-22 13:14               ` Ian Kent
2019-05-22 13:55                 ` Karel Zak
2019-05-23  1:27                   ` Ian Kent

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=75f27b68-52ff-7f6b-b031-0637ba04df2f@gmail.com \
    --to=bruce.dubbs@gmail.com \
    --cc=kzak@redhat.com \
    --cc=raven@themaw.net \
    --cc=util-linux@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.