[Top] [All Lists]

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

To: stan@xxxxxxxxxxxxxxxxx
Subject: Re: howto keep xfs directory searches fast for a long time
From: Michael Monnerie <michael.monnerie@xxxxxxxxxxxxxxxxxxx>
Date: Wed, 15 Aug 2012 10:59:33 +0200
Cc: xfs@xxxxxxxxxxx
In-reply-to: <502A83F2.6070805@xxxxxxxxxxxxxxxxx>
Organization: it-management http://it-management.at
References: <6344220.LKveJofnHA@saturn> <1888734.iS4pqoU89M@saturn> <502A83F2.6070805@xxxxxxxxxxxxxxxxx>
User-agent: KMail/4.7.2 (Linux/3.5.1-zmi; KDE/4.7.2; x86_64; ; )
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: signature.asc
Description: This is a digitally signed message part.

<Prev in Thread] Current Thread [Next in Thread>