On Sunday 24 July 2011 22:48:23 Always Learning wrote: > > On Sun, Jul 24, 2011 at 5:13 PM, R P Herrold <herrold at owlriver.com> wrote: > > > then, we look to the leading letter of the hask, to design our > > > egg carton bins. We place pix00001.jpg in directory: ./f/ and > > > pix00002.jpg in directory ./1/ and pix00003.jpg in directory > > > ./b/ and so forth -- if the directories get too full again, > > > you might go to using the first two letters of the hash to > > > perform the 'binning' process > > If the pictures are named sequentially, why not store then at a 100 per > directory structure something like this > > /pix/0/00/pix00001.jpg > > /pix/0/26/pix02614.jpg > > /pix/6/72/pix67255.jpg As I have worked on projects where the 'coder' is not willing to do any changes, I offer you another temporary solution: If the pictures are in /home/site/public_html/images, you simply need to create a tmpfs, copy the pictures there and then bind mount the tmpfs in that directory: # mkdir /home/site/ram # mount -t tmpfs -o size=200M none /home/site/ram # cp -a /home/site/public_html/images/* /home/site/ram # mount --bind /home/site/ram /home/site/public_html/images Instant performance gain, while you wait for the coder to actually fix the problem. However you should make sure that you copy the new images from the ram to disk. Maybe with inotifywatch. Keep in mind that this is only a temporary solution that should serve only as a proof that this is the problem and it needs to be fixed. Try to explain that this hack is not an actual solution. -- Best regards, Marian Marinov -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <http://lists.centos.org/pipermail/centos/attachments/20110724/0c2fc942/attachment-0004.sig>