here are my quick thoughts. First, to solve your AFR performance problem, use only 2 bricks per AFR use unify (or DHT) to combine your multiple AFR bricks into a single representation. for your loads of small files use the Berkeley DB translator, as it's apparently much faster for small files. ( you may need to use the switch scheduler within unify to make sure the right files get to the right bricks.) Beyond that, hopefully someone with a deeper understanding of all the translators can help At 05:18 PM 1/4/2009, aka_Red=5FLion wrote: >Hello! > >There is a challenge to build a robust network-based storage >glusterfs. All of course good, but there is a problem - there is no >scalability (the number of units will vary with time) and not very >good speed afr (need to work as a database for storage of about >gigabytes and temporaly (no more than 2 seconds, then delete) small >files). Can you help with a sketch configuration? > >P.S. Tire tried scheme afr ha has not yet been particularly pleased >with ... By the way, but as a work ha? > >// sorry about my bad english > >_______________________________________________ >Gluster-users mailing list >Gluster-users at gluster.org >http://zresearch.com/cgi-bin/mailman/listinfo/gluster-users
