On Tuesday 22 July 2014 07:04:54 Jeff Darcy wrote: > > One possible solution is to convert directories into files managed by > > storage/posix (some changes will also be required in dht and afr > > probably). We will have full control about the format of this file, > > so we'll be able to use the directory offset that we want to avoid > > interferences with upper xlators in readdir(p) calls. This will also > > allow to optimize directory accesses and even minimize or solve the > > problem of renames. > > Unfortunately, most of the problems with renames involve multiple > directories and/or multiple bricks, so changing how we store directory > information within a brick won't solve those particular problems. I know there are many problems that this solution doesn't address. I should have specified that I was talking about the effect of a rename causing a file to reside in the wrong brick (needing a rebalance to move it to the right place). With this implementation it would be easier to avoid this problem. > > Additionally, this will give the same reliability to directories that > > files have (replicated or dispersed). > > If it's within storage/posix then it's well below either replication or > dispersal. I think there's the kernel of a good idea here, but it's > going to require changes to multiple components (and how they relate to > one another). Well, even if this is implemented in storage/posix, many other components, including dht, afr and ec, will need to be aware of that to make it work, as you said. It's a big change, but the benefits are also very interesting. I haven't analyzed all details yet, but I think that many of the complexities in directory management inside dht and afr could be eliminated or simplified significantly. It could also improve directory browsing speed. Xavi _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel
