[Tfug] When RTFM is not enough

[Bowie J. Poag]

On Saturday 06 July 2002 01:40 pm, johngalt wrote:
> > If anyone tells you to use "find", double up your fist and just pound the
> > snot out of them.  When they lose consciousness, drag their body into a
>
> The problem with "find" is what?

Well, lets see... People who use "find" tie up enormous system resources, 
generate thousands of interrupts, spike processor usage, spike DMA usage, and 
throw perfectly usable results out the window while trying to find one or two 
needles in a haystack that can extend over networks, multiple devices, slow 
devices, you name it... and they do this ... every ...single ...time ...they 
..run ..it .. 

Versus people who search with updatedb, or the du -k trick I suggested..they 
incur a one-time system penalty that returns exactly what theyre looking for, 
with a minimum amount of system disruption..No more than any other simple 
grep would.

Lets look at the stats... Heres what /proc/interrupts for the drive looks like 
when running "find" :

find:
 15:      42910          XT-PIC  ide1    (before..)
 15:      46155          XT-PIC  ide1    (after...)


(46155 - 42910) = 3245.  3,245 separate interrupts occured while trying to 
find a file with "find". And with those 3000+ interrupts, DMA got hit, 
performance suffered, and everyone else on the box lagged while you hogged 
all the resources temporarrily.  Now, lets look at the same search process 
using updatedb / the du -k trick:

updatedb / du -k: 
 15:      46932          XT-PIC  ide1    (before..)
 15:      46934          XT-PIC  ide1    (after....)

A grand total of two interrupts were used to search for a file.  TWO! 

Case closed.

>
> Why litter your disk with index files to grep later?
>

1 file != litter. 

[03:10:16][medusa][~] root : du -k / >/foo ; ls -l /foo
-rw-r--r--    1 root     root       565758 Jul  7 15:13 /foo

Heaven forbid we should sacrifice an entire 560KB! Good lord, thats insane!

Incidentally, what the hell do you think updatedb does?


Cheers,
Bowie