Message-ID: <20070509170646.C12805@cbr.shaptech.com>
Date:	Wed, 9 May 2007 17:06:46 -0500
From:	Shapor Naghibzadeh <shapor@...por.com>
To:	linux-ext4@...r.kernel.org
Subject: poor performance of mount due to libblkid


There is a serious performance degradation with the mount command after
mounting many unique devices when compiled with libblkid support.  A simple
"mount" command to display the list of mounted filesystem can take minutes to
run.  This is due to a call to libblkid's blkid_get_cache and a
relatively large /etc/blkid.tab (tens of thousands of lines, a few megs in
size).

The file is able to grow to a large size because it does not know that device
mapper devices have been removed and will never be created again.  Neither the
libblkid api nor blkid command line appear to even provide a facility for
removing entries if you wanted to do so manually on device removal.

Combined with no (reasonable) bound on the size of the blkid.tab file, this
causes the mount command to get slower over time.  To make matters worse, the
cost of reading the file in to memory is n-squared (which happens every time
the mount command is run, even with "-h" for help!).  I have provided a simple
shell script which reproduces the problem and generates a graph of mount's
running time using gnuplot: http://www.shapor.com/libblkid/

I intended to run 100,000 iterations but even 16,000 took almost a day to run
on a fast computer (2.8GHz P4).  Simply removing the blkid.tab immediately
restores the original performance at iteration zero.

Conclusions:
1) mount has libblkid support hacked in sloppily.  It shouldn't attempt to
read the blkid.tab unless it is trying to guess the filesystem type.  Even if
it is, what is the point?  Is reading blkid.tab and parsing xml really an
optimization over reading the superblock (which we are about to do when we
mount the filesystem) and determining the fs type?  It doesn't even seem to
help the normal case, and really hurts the worst case badly.  If mount is to
use the file, it should scan through it only in the case it is actually
trying to detect the filesystem type, and stop when it finds the entry.

2) The in-memory data structure of the blkid cache was not designed with scale
in mind.  It should not have to scan the entire list locate a device,
which happens on every insert when reading it.

3) The use of XML in /etc is not very unixy.  It is difficult for both
computers and humans to parse.

This list appeared to be the best place to post my findings with mount and the
libblkid component of e2fsprogs.  If there is a better place, please let me
know.

Regards,
Shapor
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists