This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 97924 - mount -l extremely slow
mount -l extremely slow
Status: CLOSED WORKSFORME
Product: Red Hat Enterprise Linux 2.1
Classification: Red Hat
Component: clumanager (Show other bugs)
2.1
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Lon Hohberger
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-06-24 02:05 EDT by Nick Strugnell
Modified: 2007-11-30 17:06 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-06-23 10:45:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Nick Strugnell 2003-06-24 02:05:41 EDT
Description of problem:  mount -l is extremely slow in returning, taking nearly a minute on a system with 25 mount points.  This problem only manifested itself when upgrading from kernel e.16summit to e.24summit. We have yet to test under e.25summit.  Version-Release number of selected component (if applicable):  2.11g-6  How reproducible:  always  Steps to Reproduce: 1. run 'mount -l' 2. 3.      Actual results:  command takes 40-60 seconds to return  Expected results:  command should return immediately  Additional info:  This is particularly problematic in failover clusters using Red Hat Cluster Manager, as the failover script runs mount -l for every filesytem to be mounted. In our case, this results in a failover taking 10-15 mintues which is unacceptable.  A workaround for this is to apply the following patch in /usr/share/cluster/services:  --- svclib_filesystem.dist      Mon Jun 23 18:11:02 2003 +++ svclib_filesystem   Mon Jun 23 18:11:23 2003 @@ -110,7 +110,7 @@                         real_dev=$tmp_dev                         return $YES                 fi -       done < <(mount -l | awk '{print $1,$3,$7}' | sed -e "s/\[\|\]//g") +       done < <(mount | awk '{print $1,$3,$7}' | sed -e "s/\[\|\]//g")          return $NO  }  This has been tested on clumanager-1.0.19-2  You must also ensure that the cluster manager configuration contains filesystems specified by block device name, rather than by label.
Comment 1 Sujan 2003-06-24 04:21:30 EDT
mount -l work fine in most of the environment , but take longer time on X440 
with fast200 mount points
Comment 2 Elliot Lee 2003-07-22 12:26:00 EDT
It'd help to have a bug report with newlines in it.
Comment 3 Nick Strugnell 2003-07-22 12:40:48 EDT
Bug was originally submitted using mozilla-1.0.1-26 as shipped with RHL 8 - not
my fault if bugzilla is incapable of wrapping text.

Repasted and manually newlined for your convenience:

Description of problem:

mount -l is extremely slow in returning, taking nearly a minute on a system with
25 mount points.  This problem only manifested itself when upgrading from kernel
e.16summit to e.24summit. We have yet to test under e.25summit.

Version-Release number of selected component (if applicable):

2.11g-6

How reproducible:

always

Steps to Reproduce:

1. run 'mount -l'
2.
3.

Actual results:

command takes 40-60 seconds to return

Expected results:

command should return immediately

Additional info:

This is particularly problematic in failover clusters using Red Hat Cluster
Manager, as the failover script runs mount -l for every filesytem to be mounted.
In our case, this results in a failover taking 10-15 mintues which is
unacceptable.  A workaround for this is to apply the following patch in
/usr/share/cluster/services:

--- svclib_filesystem.dist      Mon Jun 23 18:11:02 2003 +++ svclib_filesystem 
 Mon Jun 23 18:11:23 2003 @@ -110,7 +110,7 @@
 real_dev=$tmp_dev                         return $YES                 fi -    
  done < <(mount -l | awk '{print $1,$3,$7}' | sed -e "s/\[\|\]//g") +      
done < <(mount | awk '{print $1,$3,$7}' | sed -e "s/\[\|\]//g")          return
$NO  }  

(Sorry, couldn't work out what the patch was supposed to look like with newlines)

This has been tested on clumanager-1.0.19-2  You must also ensure that the
cluster manager configuration contains filesystems specified by block device
name, rather than by label.
Comment 4 Elliot Lee 2003-08-13 12:25:56 EDT
Thanks for the repost.

I'd like to know how to reproduce this bug with 'mount', so I'm going to add myself to the Cc 
list, but the workaround you provided is probably the best approach, since the problem 
with mount isn't obvious. I'll reassign the bug to clumanager's owner.
Comment 5 Lon Hohberger 2003-08-13 13:36:35 EDT
Different storage controllers have different performance characteristics in
different environments.

I've heard that there's a setting on the FAStT 200 controllers allowing one to
set the "File system type" to "Database" (?).  This may help things a bit.

The 'mount -l' command in the service scripts is used solely in the case where a
user uses a file system label.  This is an undocumented and unsupported feature;
so removing it wouldn't hurt.  However, I haven't seen this problem before.

Could you run:

strace -rT mount -l &> output.txt

on your cluster and attach the resulting output.txt?

Comment 6 Lon Hohberger 2003-09-02 15:42:58 EDT
ping...
Comment 7 Lon Hohberger 2004-01-05 09:06:16 EST
ping 2...
Comment 8 Nick Strugnell 2004-01-05 09:40:56 EST
I cannot help any further with this bug as obviously I am no longer on
client site. Unless Sujan, (who is on the cc list) responds this will
be difficult to resolve.

Sujan, can you please run:

strace -rT mount -l &> output.txt

on the active node of the cluster and either attach the output to this
bugzilla report, or send it directly to me?

Cheers,
Nick
Comment 9 Nick Strugnell 2004-01-05 09:44:41 EST
As an aside, it would be unwise to remove the 'specify by label'
functionality from clustermanager as I know of several customers using
it in mission-critical deployments.

It often has to be used in clusters using Compaq servers along with
servers from other manufacturers, as on the compaq server the first
SAN LUN will be sda, whereas on e.g. an IBM it will be sdb (assuming
only one internal drive). This is because the Compaq uses cciss/c0d0
as the internal drive whereas the IBM would use sda.

Comment 10 Lon Hohberger 2004-01-05 09:47:12 EST
Actually, I meant only for this particular customer as a workaround.
Comment 11 Lon Hohberger 2004-02-09 10:46:00 EST
... Any information which would prevent closure of this as
'WORKSFORME'?  Like the strace?

Note You need to log in before you can comment on or make changes to this bug.