<div dir="ltr">Hello,<div>I used glusterFS 3-4 years ago and I&#39;m looking at it as a potential solution for creating an HTTP accessible internal cache of files for a project I&#39;m working on. This doesn&#39;t need to be super scalable in terms of the number of simultaneous users, but relatively consistent access in the sub second range per file would be important.</div><div><br></div><div>I currently have images stored directly on disk, with an Apache service sitting on top to provide the files back on demand.</div><div>I have a naming structure set up such that the first two characters in a file name provide a folder path - file &quot;abc123.txt&quot; sits at /my/data/a/b/abc123.txt</div><div>This is how I avoid having millions of files in a single directory. This can be extended as needed, of course, and is managed with a simple apache rewrite rule.</div><div><br></div><div>If I need to cache and expose millions to billions of relatively small files (average file size 50kb), where am I likely to encounter problems with glusterFS? </div><div>Are there block size issues? </div><div>inode issues? </div><div>Obviously raw disk storage is a constraint, but are there any others I should be aware of when planning this service?</div><div><br></div><div>Can I point Apache at an NFS filesystem mounted glusterFS volume and do the same kind of service I&#39;m doing currently? </div><div>Is there a better way to do this?</div><div><br></div><div>Do I need to do the same kind of file routing I&#39;m doing currently, within gluster? </div><div>That is to say, will I still need to store data in my gluster volume at /my/gluster/data/a/b/abc123.txt?</div><div><br></div><div>Thanks!</div><div>Josh Harrison</div></div>