> > IOW, given a d_off and a common routine, pass the d_off with this (i.e > > current xlator) to get a subvol that the d_off belongs to. This routine > > would decode the d_off for the leaf ID as encoded in the client/protocol > > layer, and match its subvol relative to this and send that for further > > processing. (it may consult the graph or store the range of IDs that any > > subvol has w.r.t client/protocol and deliver the result appropriately). > > What happens to this scheme when bricks are repeatedly added/removed? IIUC, the leaf xlator encoding proposed should be performed during graph initialization and would remain static for the lifetime of the graph. When bricks are added or removed, it would trigger a graph change, and the new encoding would be computed. Further, it is guaranteed that ongoing (readdir) FOPs would complete in the same (old) graph and therefore the encoding should be unaffected by bricks being added/removed. _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
