> An alternative would be to convert directories into regular files from > the brick point of view. > > The benefits of this would be: > > * d_off would be controlled by gluster, so all bricks would have the > same d_off and order. No need to use any d_off mapping or transformation. I don't think a full-out change from real directories to virtual ones is in the cards, but a variant of this idea might be worth exploring further. If we had a *server side* component to map between on-disk d_off values and those we present to clients, then it might be able to do a better job than the local FS of ensuring uniqueness within the bits (e.g. 48 of them) that are left over after we subtract some for a brick ID. This could be enough to make the bit-stealing approach (on the client) viable. There are probably some issues with failing over between replicas, which should have the same files but might not have assigned the same internal d_off values, but those issues might be avoidable if the d_off values are deterministic with respect to GFIDs. _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
