Gluster limits and best practices

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Now that Gluster is dependent on the fs limits of the bricks, how do you ensure you distribute files in a way to not hit those limits?

On Jan 12, 2012, at 4:05 PM, Philip Poten wrote:

> 2012/1/12 Drew Kutcharian <drew at venarc.com>
> Thanks Amar, so what are the hard limits of Gluster as far as number of directories and files in directories and i-nodes?
> 
> Those of the filesystem used by the gluster bricks.
> 
> We have 10K files in one directory, and a listing takes around 5-15 seconds (it's slow), depending on load. However, this has no impact on our app, since the app knows the path of the file it requests, which makes it less about glusterfs and more about the underlying fs.
> 
> My advice would be, if your app uses pre-determined filenames (aka image hosting use case), use a directory layout that allows you to comfortably do maintenance work (backup), and if you need to do directory listings in your app (no known file requests, aka mailserver use case) don't use glusterfs or re-engineer your app accordingly.
> 
> cheers,
> Philip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gluster.org/pipermail/gluster-users/attachments/20120113/e73218c9/attachment.htm>


[Index of Archives]     [Gluster Development]     [Linux Filesytems Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux