1 |
On Sat, May 24, 2008 at 04:49:09PM -0500, Penguin Lover reader@×××××××.com squawked: |
2 |
> Is there any way to speed up the du command? I mean short of having |
3 |
> cron run it on target directories and store results. (not really |
4 |
> speeding up but at least not having to wait for a result) |
5 |
> |
6 |
> I've seen various mention of du being slow but don't recall any |
7 |
> mentions of how to speed it up. |
8 |
> |
9 |
> I use Reiserfs with default sizes. In some situations like a large |
10 |
> cache of nntp messages of several GB. I might wait 5-10 minutes or more |
11 |
> for du to get the size of the directory. |
12 |
> |
13 |
> Are there other file systems that can return a result of `du' faster? |
14 |
> |
15 |
> I'm curious how `df' computes sizes so much quicker. Even after |
16 |
> rm'ing a large amount of data... `df' sees the difference right away. |
17 |
> |
18 |
> Or maybe there is some other tool or technique that can quickly tell |
19 |
> me the size of a directory or set of directories. |
20 |
|
21 |
I am pretty sure the problem with du is that it actually looks, |
22 |
recursively, at every single file and computes the size that way. So |
23 |
the time you have to wait is mostly due to disk IO (and caching would |
24 |
also explain why if you run du twice in a row the answer returns much |
25 |
more quickly). So, if you know what the bottle-neck directory is (for |
26 |
example, the directory of nntp messages), the tricks in |
27 |
|
28 |
http://gentoo-wiki.com/TIP_Speeding_up_portage |
29 |
|
30 |
should probably work just as well. |
31 |
|
32 |
HTH, |
33 |
|
34 |
W |
35 |
-- |
36 |
"You're very sure of your facts, " he said at last, "I |
37 |
couldn't trust the thinking of a man who takes the Universe |
38 |
- if there is one - for granted. " |
39 |
Sortir en Pantoufles: up 533 days, 21:55 |
40 |
-- |
41 |
gentoo-user@l.g.o mailing list |