[Bug 1686679] Re: [SRU] Ubuntu16.04 : autofs takes extreamly long with large number of direct maps
Eric Desrochers
eric.desrochers at canonical.com
Tue Jun 13 18:00:57 UTC 2017
** Description changed:
[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
+ 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.
+ local file system instead.
[Test Case]
- * Create an autofs direct mount map with large direct mappings (eg:
+ * 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.
+ * 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
+ * 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.
+ me and customer have positive test results with automount start timings.
+
+ * What releases to fix
+
+ $ git tag --contains 67e7d613a4b09eeffc57ab44a7acb52027d897b2
+ release_5_1_2
+
+ $ rmadison autofs5
+ [...]
+ autofs5 | 5.1.1-1ubuntu3 | xenial | all
+ autofs5 | 5.1.1-1ubuntu3 | yakkety | all
+ autofs5 | 5.1.2-1ubuntu1 | zesty | all
+ autofs5 | 5.1.2-1ubuntu1 | artful | all
+
+ Only Xenial and Yakkety are affected since Zesty and Artful already has
+ the upstream fix because it's version 5.1.2.
[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
--
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.
* What releases to fix
$ git tag --contains 67e7d613a4b09eeffc57ab44a7acb52027d897b2
release_5_1_2
$ rmadison autofs5
[...]
autofs5 | 5.1.1-1ubuntu3 | xenial | all
autofs5 | 5.1.1-1ubuntu3 | yakkety | all
autofs5 | 5.1.2-1ubuntu1 | zesty | all
autofs5 | 5.1.2-1ubuntu1 | artful | all
Only Xenial and Yakkety are affected since Zesty and Artful already
has the upstream fix because it's version 5.1.2.
[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