util-linux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Karel Zak <kzak@redhat.com>
To: Bruce Dubbs <bruce.dubbs@gmail.com>
Cc: Ian Kent <raven@themaw.net>, util-linux@vger.kernel.org
Subject: Re: Using the upcoming fsinfo()
Date: Wed, 15 May 2019 13:27:34 +0200	[thread overview]
Message-ID: <20190515112734.vlhloudkpieccdfe@ws.net.home> (raw)
In-Reply-To: <75f27b68-52ff-7f6b-b031-0637ba04df2f@gmail.com>

On Mon, May 13, 2019 at 11:04:50AM -0500, Bruce Dubbs wrote:
> On 5/13/19 4:08 AM, Karel Zak wrote:
> > 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.

Yes, we need to support both versions. 

The new version of the API will significantly improve performance in
situation when you need more information about a mountpoint (for
example fstype, device name, mount options, etc.) -- nice example is
umount or remount.

Now we parse all /proc/self/mountinfo to get one line from the file.
This is problem on systems with huge number of the mountpoints and on
systems where kernel mount table is modified very often and userspace
need to be synchronized with the table (e.g. systemd dependencies,
etc).

All this is about a new syscall fsinfo(). The new mount API (mount(2)
replacement) is another story :-)

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

For end users all the changes should be invisible. The same libmount
binary should be usable everywhere independently on the new syscalls.

It's possible that we will extend the library API to make it easy for
applications to get info about a mountpoint without mountinfo file
parsing, but it should be also possible to do it with mountinfo as
fallback if there is no fsinfo().

    Karel

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

  parent reply	other threads:[~2019-05-15 11:43 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
2019-05-14  0:04     ` Ian Kent
2019-05-15 11:27     ` Karel Zak [this message]
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=20190515112734.vlhloudkpieccdfe@ws.net.home \
    --to=kzak@redhat.com \
    --cc=bruce.dubbs@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).