]> err.no Git - linux-2.6/commit
[GFS2] Clean up/speed up readdir
authorSteven Whitehouse <swhiteho@redhat.com>
Wed, 17 Jan 2007 15:09:20 +0000 (15:09 +0000)
committerSteven Whitehouse <swhiteho@redhat.com>
Mon, 5 Feb 2007 18:37:04 +0000 (13:37 -0500)
commit3699e3a44bf56e0cd58c97e8655f375ad9b65d9d
tree9ac31dd5b99373614f0cd52cc5a41536aeea271e
parenta8d638e30e768adc6956541f79f7bf05139ba475
[GFS2] Clean up/speed up readdir

This removes the extra filldir callback which gfs2 was using to
enclose an attempt at readahead for inodes during readdir. The
code was too complicated and also hurts performance badly in the
case that the getdents64/readdir call isn't being followed by
stat() and it wasn't even getting it right all the time when it
was.

As a result, on my test box an "ls" of a directory containing 250000
files fell from about 7mins (freshly mounted, so nothing cached) to
between about 15 to 25 seconds. When the directory content was cached,
the time taken fell from about 3mins to about 4 or 5 seconds.

Interestingly in the cached case, running "ls -l" once reduced the time
taken for subsequent runs of "ls" to about 6 secs even without this
patch. Now it turns out that there was a special case of glocks being
used for prefetching the metadata, but because of the timeouts for these
locks (set to 10 secs) the metadata was being timed out before it was
being used and this the prefetch code was constantly trying to prefetch
the same data over and over.

Calling "ls -l" meant that the inodes were brought into memory and once
the inodes are cached, the glocks are not disposed of until the inodes
are pushed out of the cache, thus extending the lifetime of the glocks,
and thus bringing down the time for subsequent runs of "ls"
considerably.

Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
fs/gfs2/dir.c
fs/gfs2/dir.h
fs/gfs2/glock.c
fs/gfs2/glock.h
fs/gfs2/incore.h
fs/gfs2/ops_export.c
fs/gfs2/ops_file.c
fs/gfs2/super.c
fs/gfs2/sys.c