On Mon, Aug 13, 2012 at 06:44:34PM +0200, Michael Monnerie wrote: > I guess the best I can do is run du/find every morning to pre-fill the > inode caches on that VM, so when someone connects the search runs fast. You're doing it wrong. This is exactly what updatedb (run via cron) and locate (the updatedb search tool) are designed for. $ time locate xfs_admin ..... real 0m0.618s user 0m0.608s sys 0m0.004s $ $ time find / -name xfs_admin* .... real 0m18.045s user 0m2.936s sys 0m9.293s $ time find / -name xfs_admin* > /dev/null 2>&1 real 0m1.794s user 0m0.688s sys 0m1.068s $ time find / -name xfs_admin* > /dev/null 2>&1 real 0m1.752s user 0m0.724s sys 0m0.984s $ time find / -name xfs_admin* > /dev/null 2>&1 real 0m1.768s user 0m0.732s sys 0m0.996s locate is 3x faster than even a cached find on a filesystem with a million inodes in it and enough RAM to cache them all. And if you have limited RAM, (i.e. cold cache) it is 30x faster than running the find on a RAID0 of SSDs that can do > 90,000 random 4k read IOPS. The differences for spinning rust will be much, much greater... Use the right tool for the job.... > The current VM shows this: > > # df -i /disks/big1/ > Filesystem Inodes IUsed IFree IUse% Mounted on > /dev/mapper/sp1--sha 1717934464 1255882 1716678582 1% /disks/big1 > # df /disks/big1/ > Filesystem 1K-blocks Used Available Use% Mounted on > /dev/mapper/sp1--sha 8587585536 6004421384 2583164152 70% /disks/big1 > > So 6TB data in 1.3 mio inodes. The VM caches that easily, seems that's > the only real thing to optimize against. > > http://xfs.org/index.php/XFS_FAQ#Q:_I_want_to_tune_my_XFS_filesystems_for_.3Csomething.3E I appreciate the sentiment, but as the the person that wrote the original entry and directs the most people to it, I'm probably just going to remove this addition. The whole point of that FAQ is to say "unless you *know* you have a problem, don't touch anything". What you've added essentially says "if you *think* you might need <something>, then do...". This train of thought is *exactly* what the FAQ entry is advising *against* doing because in most cases what people -think- they need is incorrect or misguided. You've even provided a great example to emphasise the point the entry is making - you need to understand the workload before tweaking knobs. Your workload is occassional fast searches of files, which is exactly what updatedb/locate provides without kernel or filesystem tweaks... > CFQ seems bad, but there's no documented way out of that. If you know what CFQ is, then you know how to change it. If you don't know what it is, then you don't know enough to make an enlightened choice as a replacement. If you lacking knowledge of basic storage concepts and setup, then you're reading the wrong document. Google is only a browser tab away. BTW, if you want to add "how to tune XFS" entries, then create a completely new wiki page about it that first points in big red, shiny letters that the above FAQ entry should be read first, and that questions about optimising XFS for bonnie++ and other benchmarks will be directed to /dev/null. Structure it to provide information about the basics - alignment, striping, data layout, metadata layout, RAID configurations, etc and how the different XFS mkfs and mount options interact with the different storage configurations. If we are going to provide tuning guidelines on the XFS wiki, then it needs to be structured, comprehensive and correct. If you want random bits of marginally valid information abou ttuning XFS from random websites around the web, Google is only a browser tab away.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
