On 04/06/2010 04:32 PM, Krzysztof Strasburger wrote: > On Tue, Apr 06, 2010 at 02:51:49PM +0800, Kali Hernandez wrote: > >> So basically this means no solution is really good as for glusterfs 3.0? >> > As for now, there is (probably) not. IMHO it would be useful to add an > option to DHT, to use load balancing approach instead of hash function. > Combined with no-hashed-lookup, this would effectively restore the > functionality of unify, at a cost of stat'ing each filesystem before file > creation. I understand that this approach does not scale, but the additional > cost is acceptable for a small number of subvolumes. > I'm not really sure of what would the best option be. However, IMHO too, this limitation cracks the whole purpose of the glusterfs. What use do I have for a distributed filesystem which is (eventually) unable to store a file when it does actually have free space to allocate it? In an environment where a lot of small files are to be stored mixed along with some others (not so many) huge ones, this means most probably you will run into a situation where the cluster report no free space even if it is. >> Does the Unify translator work properly in 2.0.x? >> > Seems to work, I'm using it ;). > I have just downgraded back to 2.0 and I'm right now trying the Unify. However to copy all the data back into the cluster (500+ Gb) over the net is a real pain and will take a lot of time given the read/write performance (I have all the data on another glusterfs volume, and reading to one + copying to the new one result in ~ 2.5 Mb/s effective speed). The worst point on using Unify, for me, is the need of the namespace child. As I can't risk on having a SPOF there, I had to take 2 nodes out for making the namespace node, thus loosing ~ 40 Gb of effective storage size. Any better config suggestion is more than welcome :-) -kali-
