2

I'm confused. I've asked several questions in the past asking for the "most efficient" way of doing something:

This time though, when I asked what the most efficient method for calculating disk usage, the question was placed on hold: https://unix.stackexchange.com/questions/188006/whats-the-most-efficient-way-to-find-out-what-is-consuming-disk-space

The question originally ended with asking "What's a faster way of doing this" (which admittedly is open-ended and subjective). I have since modified the question to once again state "What is the most efficient way of doing this?"

Is this still out of scope? If so, why were the other questions allowed?

6

One thing to realize about how Stack Exchange works: The close reason displayed isn't always what all the voters picked. It displays the most popular one. Personally, I voted to close as unclear; let me explain why:

du works by going through all directories, reading all the entries and stating them. It adds up and prints the sizes as it goes. Pretty much, this is the only way to do what it does within the Unix API. That said, there are more or less optimal ways to do this, but they're all reasonably close.

There are a few ways to not actually do the above work (e.g., caching the results and avoiding re-scanning unchanged directory trees—you can do this, depending on the filesystem in use), moving the work to somewhere its faster (on a file server instead of the client), etc. All these are very setup-specific. And, e.g., if you're only checking once, not repeatedly, that cached version is going to be slower. You didn't give us any details.

You presented us with a machine that takes much longer. It'd be interesting to answer why it takes longer—but again, no details. Maybe the machine just has a thousand times more files? Maybe it has slow disks? Maybe it's scanning a slow NFS mount? Maybe there are other processes competing for I/O? Maybe the hardware is failing, and du is actually waiting for disk I/O retries?

More or less, you've asked "what's the fastest du?". If you compare it to the other questions you listed, you'll notice the others are more focused and more detailed. They're detailed enough that someone answering can actually run benchmarks that'll likely apply to your situation as well. (I suspect this is where the "opinion based" reason comes in; without those details, there isn't a clear way to answer which du, within the set of reasonably efficient ones, is fastest).

  • Ah, I see your point. Thanks for clarifying. – Mike B Mar 5 '15 at 4:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .