2017-05-01 20:08 GMT+02:00 Pranith Kumar Karampuri <pkarampu at redhat.com>:> Filename can be renamed and then we lost the link because hash will be > different. Anyways all these kinds of problems are already solved in > distribute layer.Filename can be renamed even with the current architecture. How do you change the GFID after file rename ? In the same way you can re-hash the file.> I am sorry at the moment with the given information I am not able to wrap my > head around the solution you are trying to suggest :-(.mine was just a POC. tl;dr: if you can save a mapping between files and brick, inside the gluster cluster, you'll get much more flexibility, no SPOF and no need for dedicated metadata servers.> At the moment, brick-splitting, inversion of afr/dht has some merit in my > mind, with tilt towards any solution that avoids this inversion and still > get the desired benefits.What is brick-splitting ? Any docs about this ?
On 05/01/2017 02:13 PM, Gandalf Corvotempesta wrote:> What is brick-splitting ? Any docs about this ?In some responses that I made today, the idea may be present. I searched (for about 3 minutes) to find older references to this thought, but was not successful. So here goes, Brick splitting (I think was first proposed by Jeff Darcy) is to create more bricks out of given storage backends. IOW, instead of using a given brick as is, create sub-dirs and use them as bricks. Hence, given 2 local FS end points by the user (say), instead of creating a 1x2 volume, create a nx2 volume, with n sub-dirs within the given local FS end points as the bricks themselves. Hence, this gives us n units to work with than just one, helping with issues like +1 scaling, among others.