** 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@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]
  
- 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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1686679

Title:
  [SRU] Ubuntu16.04 : autofs takes extreamly long with large number of
  direct maps

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/autofs5/+bug/1686679/+subscriptions

-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to