group.of.nepali.translators team mailing list archive
-
group.of.nepali.translators team
-
Mailing list archive
-
Message #14352
[Bug 1686679] Re: [SRU] Ubuntu16.04 : autofs is extremely long with large number of direct maps
This bug did not have its tasks automatically modified because they are
about the autofs5 package, which only exists in Precise, and not the
autofs package.
** Package changed: autofs5 (Ubuntu) => autofs (Ubuntu)
** Changed in: autofs (Ubuntu Xenial)
Status: Fix Committed => Fix Released
** Changed in: autofs (Ubuntu Yakkety)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1686679
Title:
[SRU] Ubuntu16.04 : autofs is extremely long with large number of
direct maps
Status in autofs package in Ubuntu:
Fix Released
Status in autofs source package in Xenial:
Fix Released
Status in autofs source package in Yakkety:
Fix Released
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@node1:~# time service autofs start
real 3m5.481s
user 0m0.256s
sys 0m0.080s
root@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
$ rmadison -u debian autofs5
autofs5 | 5.1.2-1 | unstable | all
- Ubuntu : Only Xenial and Yakkety are affected.
Zesty and Artful already has the upstream fix because they are at version 5.1.2.
- Debian : unstable also has the fix already.
[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/autofs/+bug/1686679/+subscriptions