[Bug 1686679] Re: [SRU] Ubuntu16.04 : autofs takes extreamly long with large number of direct maps
Hua Zhang
joshua.zhang at canonical.com
Thu May 25 06:52:48 UTC 2017
** Description changed:
[Impact]
- autofs service in xenial takes extremely long time since its creating
- the directory hierarchy for all direct mounts maps, thus it will take
- too long to make all the automount shares available when using autofs
- with large direct mappings, customer is complaining about this point. So
- we need to backport the following upstream patch.
+ autofs service in xenial takes extremely long time since it parses the
+ mount table /etc/mtab in contained_in_local_fs() to determine if the mount
+ patch would be created on a local file system, that means startup process will read /etc/mtab for every mount, so the performance is extremely low. The customer is complaining about this point, we need to backport the
+ following upstream patch.
https://git.kernel.org/pub/scm/linux/storage/autofs/autofs.git/commit/?id=67e7d613a4b09eeffc57ab44a7acb52027d897b2
+
+ This fix patch removes contained_in_local_fs, and use fs.f_type in is_remote_fstype() to determine if the mount patch would be created on a
+ local file system instead.
[Test Case]
* Create an autofs direct mount map with large direct mappings (eg:
- more than 20k)
+ 8k), below is the test script I used.
- * Start autofs service to see if it will take too much time to
- automount all mappings.
+ echo "/- auto.direct --timeout 60" >> /etc/auto.master
+ END=8000
+ for i in $(seq 1 $END); do echo $i; echo "/test/samba/test"$i" -fstype=cifs,rw,username=hua,password=password ://192.168.99.169/share" >> /etc/auto.direct; done
+
+ * Start autofs service to see if it will take too much time, below is my
+ result before/after applying the fix patch.
+
+ root at node1:~# time service autofs start
+ real 3m5.481s
+ user 0m0.256s
+ sys 0m0.080s
+ root at node1:~# time service autofs start
+ real 0m0.833s
+ user 0m0.000s
+ sys 0m0.004s
[Regression Potential]
- With this upstream patch, we can avoid creating path compnents on remote
- file system unless that file system is the root file system. so
- theoretically there is no regression potential.
+ * We are well aware of the principle of this fix patch - avoiding parsing
+ the mount table to improve startup time, so seems infinitely better for
+ all cases.
+
+ * This fix from upstream has been backported into Redhat as well, and both
+ me and customer have positive test results with automount start timings.
[Other Info]
-
- Redhat [1] also already backported the following patch, see: https://bugzilla.redhat.com/show_bug.cgi?id=1440769
+
+ * Redhat [1] also already backported the following patch, see: https://bugzilla.redhat.com/show_bug.cgi?id=1440769
+ * This mailing list also discussed this problem, see: http://www.spinics.net/lists/autofs/msg01161.html
--
You received this bug notification because you are a member of Ubuntu
Sponsors Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1686679
Title:
[SRU] Ubuntu16.04 : autofs takes extreamly long with large number of
direct maps
Status in autofs5 package in Ubuntu:
Fix Released
Status in autofs5 source package in Xenial:
New
Status in autofs5 source package in Yakkety:
New
Bug description:
[Impact]
autofs service in xenial takes extremely long time since it parses the
mount table /etc/mtab in contained_in_local_fs() to determine if the mount
patch would be created on a local file system, that means startup process will read /etc/mtab for every mount, so the performance is extremely low. The customer is complaining about this point, we need to backport the
following upstream patch.
https://git.kernel.org/pub/scm/linux/storage/autofs/autofs.git/commit/?id=67e7d613a4b09eeffc57ab44a7acb52027d897b2
This fix patch removes contained_in_local_fs, and use fs.f_type in is_remote_fstype() to determine if the mount patch would be created on a
local file system instead.
[Test Case]
* Create an autofs direct mount map with large direct mappings (eg:
8k), below is the test script I used.
echo "/- auto.direct --timeout 60" >> /etc/auto.master
END=8000
for i in $(seq 1 $END); do echo $i; echo "/test/samba/test"$i" -fstype=cifs,rw,username=hua,password=password ://192.168.99.169/share" >> /etc/auto.direct; done
* Start autofs service to see if it will take too much time, below is my
result before/after applying the fix patch.
root at node1:~# time service autofs start
real 3m5.481s
user 0m0.256s
sys 0m0.080s
root at node1:~# time service autofs start
real 0m0.833s
user 0m0.000s
sys 0m0.004s
[Regression Potential]
* We are well aware of the principle of this fix patch - avoiding parsing
the mount table to improve startup time, so seems infinitely better for
all cases.
* This fix from upstream has been backported into Redhat as well, and both
me and customer have positive test results with automount start timings.
[Other Info]
* Redhat [1] also already backported the following patch, see: https://bugzilla.redhat.com/show_bug.cgi?id=1440769
* This mailing list also discussed this problem, see: http://www.spinics.net/lists/autofs/msg01161.html
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/autofs5/+bug/1686679/+subscriptions
More information about the Ubuntu-sponsors
mailing list