Re: howto keep xfs directory searches fast for a long time

[Michael Monnerie <michael.monnerie@is.it-management.at>]

[-- Attachment #1.1: Type: text/plain, Size: 1390 bytes --]

Am Dienstag, 14. August 2012, 11:59:30 schrieb Stan Hoeppner:
> All the media players have playlist and index features.  So there's
> little need for searching an entire Samba share is there?

Media Players usually connect to a Samba/NFS share, and read contents. 
Some even search for index JPGs, and present that for a sub-dir so you 
have a preview. All that is directory access.

> What you apparently require is not something that can be addressed or
> optimized by filesystem or kernel tweaks.  As Dave pointed out with
> the 'locate' example in a CLI, this kind of thing is precisely what
> databases were designed for.

Yes, I use locate on that server of course, when I have shell access 
that's just fine. The "best effort" I can do now is to run the find 
service for locate daily morning, so inodes get pre-cached, and tune 
vm.vfs_cache_pressure = 10 to keep them in the cache. This works rather 
good. I just tried a "du -s /bigdir" again, it runs within a very short 
time (<4s) even 4h after the locate run, this is good enough. Customer 
will be happy. On the old server this took >3m, on the same hardware. A 
speedup of at least 45x is what I call efficient tuning ;-)

-- 
mit freundlichen Grüssen,
Michael Monnerie, Ing. BSc

it-management Internet Services: Protéger
http://proteger.at [gesprochen: Prot-e-schee]
Tel: +43 660 / 415 6531

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs