On 02/02/2015 10:29 PM, Krishnan Parthasarathi wrote:
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
> > 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 furt
> 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
> pr
Hello,
We have a prototype of this working on the tiering forge site, and noticed that
in this scheme, each client translator needs to "know" the total number of
#bricks in the volume. We can compute that number when the graph is created,
and on a graph switch. But in some sense, a downside of
Hi,
Some parts of this topic has been discussed in the recent past here [1]
The current mechanism of each xlator encoding the subvol in the lower or
higher bits has its pitfalls as discussed in the threads and in this
review, here [2]
Here is a solution design from the one of the comments po
