linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: chenditang <chendt.fnst@cn.fujitsu.com>
To: util-linux@vger.kernel.org, linux-nfs@vger.kernel.org
Subject: [QUESTION]about libmount library performance problems
Date: Tue, 25 Sep 2012 10:02:35 +0800	[thread overview]
Message-ID: <506110BB.2070408@cn.fujitsu.com> (raw)
In-Reply-To: <5061076C.2080707@cn.fujitsu.com>

Hi util-linux@vger.kernel.org

I have 1 question which need confirm.

  in the RHEL7.0alpha version
	nfs-utils-1.2.5-3.el7.x86_64  --> use mount_libmount.c
	util-linux-2.20.1-2.el7.x86_64
  when umount a NFS directory, the mnt_table_parse_mtab() function will merge user options(/run/mount/utab) 
into mountinfo(/proc/self/mountinfo)from kernel. if the mount number is large, leading to umount a directory
time-consuming. the complexity of the algorithm is O(n(n+1)/2).

    but in the old version(RHEL6.3GA/nfs-utils-1.2.3-26.el6.x86_64(use mount.c)), only according to the parameters of umount command, 
find the corresponding record in the /etc/mtab file

  Question)*:* merg the tow file are necessary for umount a dir?

TEST LOG:
#cat mount_test.sh
#!/bin/bash
mount=/tmp/mount
if [ ! -d $mount ]; then
    mkdir -p $mount
fi
for dir in {1..8000}; do
    if [ ! -d $mount/$dir ]; then
        mkdir -p $mount/$dir
    fi
    echo mount $dir
    mount -t nfs 127.0.0.1:/ $mount/$dir
done 

# time umount /tmp/mount/1    --------->RHEL7.0alpha
real    0m2.395s
user    0m1.640s        
sys     0m0.466s

# time umount /tmp/mount/1    --------->RHEL6.3GA
real	0m0.159s
user	0m0.042s        
sys	0m0.114s


thanks.


       reply	other threads:[~2012-09-25  2:03 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <505FBE77.8030802@cn.fujitsu.com>
     [not found] ` <5061076C.2080707@cn.fujitsu.com>
2012-09-25  2:02   ` chenditang [this message]
2012-09-25 10:10     ` [QUESTION]about libmount library performance problems Karel Zak
2012-09-25 10:31       ` Karel Zak
2012-09-25 14:58         ` Karel Zak

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=506110BB.2070408@cn.fujitsu.com \
    --to=chendt.fnst@cn.fujitsu.com \
    --cc=linux-nfs@vger.kernel.org \
    --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).