* [QUESTION]about libmount library performance problems [not found] ` <5061076C.2080707@cn.fujitsu.com> @ 2012-09-25 2:02 ` chenditang 2012-09-25 10:10 ` Karel Zak 0 siblings, 1 reply; 4+ messages in thread From: chenditang @ 2012-09-25 2:02 UTC (permalink / raw) To: util-linux, linux-nfs 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [QUESTION]about libmount library performance problems 2012-09-25 2:02 ` [QUESTION]about libmount library performance problems chenditang @ 2012-09-25 10:10 ` Karel Zak 2012-09-25 10:31 ` Karel Zak 0 siblings, 1 reply; 4+ messages in thread From: Karel Zak @ 2012-09-25 10:10 UTC (permalink / raw) To: chenditang; +Cc: util-linux, linux-nfs, Chuck Lever On Tue, Sep 25, 2012 at 10:02:35AM +0800, chenditang wrote: > 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). Yes, maybe we can somehow improve the file format and the algorithm, suggestions? > 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 But we don't have mtab file in RHEL7 anymore, so we have to store the userspace specific mount options somewhere... (/run/mount/utab). The solution is to minimize number of information we have to maintain in userspace. Unfortunately it seems that for example on my system we duplicate the information: utab: retrans=20,addr=192.168.111.1 mountinfo: rw,vers=3,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600, retrans=20,sec=sys,mountaddr=192.168.111.1,mountvers=3,mountport=39755, mountproto=udp,local_lock=none,addr=192.168.111.1 (see retrans= and addr=) Maybe we can detect this situation and don't store duplicate options in userspace. The question is what happen with retrans= and addr= after remount. If I good remember there was any reason to maintain these stuff in userspace. Chuck? > Question)*:* merg the tow file are necessary for umount a dir? I guess nfs umount needs the addr= info. Karel -- Karel Zak <kzak@redhat.com> http://karelzak.blogspot.com ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [QUESTION]about libmount library performance problems 2012-09-25 10:10 ` Karel Zak @ 2012-09-25 10:31 ` Karel Zak 2012-09-25 14:58 ` Karel Zak 0 siblings, 1 reply; 4+ messages in thread From: Karel Zak @ 2012-09-25 10:31 UTC (permalink / raw) To: chenditang; +Cc: util-linux, linux-nfs, Chuck Lever On Tue, Sep 25, 2012 at 12:10:31PM +0200, Karel Zak wrote: > On Tue, Sep 25, 2012 at 10:02:35AM +0800, chenditang wrote: > > Question)*:* merg the tow file are necessary for umount a dir? Ah, do you mean -- why we need to merge all the entries when we want to work with only one mountpoint? That's good question ;-) I'll try to improve the code... Karel -- Karel Zak <kzak@redhat.com> http://karelzak.blogspot.com ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [QUESTION]about libmount library performance problems 2012-09-25 10:31 ` Karel Zak @ 2012-09-25 14:58 ` Karel Zak 0 siblings, 0 replies; 4+ messages in thread From: Karel Zak @ 2012-09-25 14:58 UTC (permalink / raw) To: chenditang; +Cc: util-linux, linux-nfs, Chuck Lever On Tue, Sep 25, 2012 at 12:31:42PM +0200, Karel Zak wrote: > > On Tue, Sep 25, 2012 at 10:02:35AM +0800, chenditang wrote: > > > Question)*:* merg the tow file are necessary for umount a dir? > > Ah, do you mean -- why we need to merge all the entries when we want > to work with only one mountpoint? That's good question ;-) I'll try > to improve the code... Improved: old version: time ./umount /tmp/mount/2255 real 0m1.254s user 0m1.002s sys 0m0.238s new version: time ./umount /tmp/mount/2244 real 0m0.332s user 0m0.111s sys 0m0.218s Karel -- Karel Zak <kzak@redhat.com> http://karelzak.blogspot.com ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2012-09-25 14:58 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <505FBE77.8030802@cn.fujitsu.com>
[not found] ` <5061076C.2080707@cn.fujitsu.com>
2012-09-25 2:02 ` [QUESTION]about libmount library performance problems chenditang
2012-09-25 10:10 ` Karel Zak
2012-09-25 10:31 ` Karel Zak
2012-09-25 14:58 ` Karel Zak
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).