Re: Using the upcoming fsinfo()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx>
 http://karelzak.blogspot.com



[Index of Archives]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux