[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
[Linux-cluster] Ls and globbing taking ridiculously long on GFS
- From: "Dylan Vanderhoof" <DylanV semaphore com>
- To: <linux-cluster redhat com>
- Subject: [Linux-cluster] Ls and globbing taking ridiculously long on GFS
- Date: Tue, 7 Nov 2006 09:47:45 -0800
I understand that a df, or ls -l that requires statting files should be
slow. However, I'm seeing ridiculous performance of just an ls, or
anything doing file globbing in directory reads.
For example:
dylanv iscsi0 /srv/rancid/logs $ time ls
[snip]
real 0m4.434s
user 0m0.000s
sys 0m0.000s
dylanv iscsi0 /srv/rancid/logs $ ls | wc -l
412
dylanv iscsi0 /srv/rancid/logs $
I consider 400 files a fairly small directory. 4.5 seconds to do an ls
is pretty bad. Its worse in a large directory, although not
porportionally to the amount of files:
dylanv iscsi0 /srv/flows/9/13 $ time ls
[snip]
real 0m31.693s
user 0m0.070s
sys 0m0.430s
dylanv iscsi0 /srv/flows/9/13 $ ls | wc -l
14274
dylanv iscsi0 /srv/flows/9/13 $
And an even larger dir:
dylanv iscsi0 /srv/flows/6/7 $ time ls
[snip]
real 1m31.849s
user 0m0.520s
sys 0m1.450s
dylanv iscsi0 /srv/flows/6/7 $ ls | wc -l
42462
dylanv iscsi0 /srv/flows/6/7 $
Any ideas for why this might be? Its clearly blocking on IO somewhere,
but I'm not sure where. Both kernel and userland are 32-bit for now.
Caching doesn't really appear to make a whole lot of difference. (A
subsequent ls on the large directory above takes 1m24.274s) What
concerns me even more is that I'm not even using DLM yet! This is with
lock_nolock.
Any suggestions or ideas are much appreciated. =)
Thanks,
Dylan
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]