[SRU] Ubuntu16.04 : autofs is extremely long with large number of direct maps
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
autofs (Ubuntu) |
Fix Released
|
Medium
|
Unassigned | ||
Xenial |
Fix Released
|
Medium
|
Hua Zhang | ||
Yakkety |
Fix Released
|
Medium
|
Hua Zhang |
Bug Description
[Impact]
autofs service in xenial takes extremely long time since it parses the
mount table /etc/mtab in contained_
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.
This fix patch removes contained_
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/
* 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 67e7d613a4b09ee
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:/
* This mailing list also discussed this problem, see: http://
description: | updated |
summary: |
- Ubuntu16.04 : autofs takes extreamly long with large number of direct - maps + [SRU] Ubuntu16.04 : autofs takes extreamly long with large number of + direct maps |
tags: | added: sts sts-sponsor sts-sru ubuntu-sponsors |
Changed in autofs5 (Ubuntu): | |
importance: | Undecided → Medium |
Changed in autofs5 (Ubuntu Xenial): | |
importance: | Undecided → Medium |
Changed in autofs5 (Ubuntu Yakkety): | |
importance: | Undecided → Medium |
description: | updated |
tags: |
added: sts-sru-needed removed: sts-sponsor sts-sru ubuntu-sponsors |
description: | updated |
description: | updated |
tags: | removed: sts |
tags: | added: sts |
tags: | added: patch-needswork |
summary: |
- [SRU] Ubuntu16.04 : autofs takes extreamly long with large number of - direct maps + [SRU] Ubuntu16.04 : autofs is extremely long with large number of direct + maps |
Changed in autofs5 (Ubuntu Xenial): | |
status: | In Progress → Fix Committed |
Changed in autofs5 (Ubuntu Yakkety): | |
status: | In Progress → Fix Committed |
tags: |
added: verification-done-xenial verification-done-yakkety removed: verification-done |
tags: |
added: sts-sru-done removed: sts-sru-needed |
Hi Hua Zhang,
you asked me to look for a nomination for Xenial.
I quickly looked and while I ack on Xenial nomination I have a few extra requests.
1. the impact isn't clear are we talking seconds, minutes, hours - if you could add a number from your tests that would be great
2. the testcase is rather unclear, imagine an SRU Team member that actually wants to do this - that is a lot of work. I'm sure you have a tst script that sets up those maps and such - please share and adapt here accordingly.
3. regression potential is clearly not "no regression potential" there could be misdetections not getting root ready, there could be issues due to building the maps late. This is not about writing the nicest words to say "no regression" it is about showing you really thought through the regressions you expect might happen in case things go wrong or thre are oversights in backporting.
4. what releases to fix ffc57ab44a7acb5 2027d897b2
$ git tag --contains 67e7d613a4b09ee
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
So IMHO Yakkety needs the fix as well, otherwise it will be a regression on upgrade.
5. the debdiff does not mention this bug number to let it be tracked by LP when things move into proposed and updates, please add them
6. the patch in the debdiff had no dep3 header, but IMHO all pacthes should have one http:// dep.debian. net/deps/ dep3/
At least add bug, Author (you) and Forwarded with a pointer to the upstream patch
I'll try to nominate X&Y but let you do the further work to adapt SRU template. Since I can't upload autofs you eventually need a core-dev anyway, but I hope my quick check help to reduce the round trips you need.