Re: RFC: d_off encoding at client/protocol layer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 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?

The result should be no different than what the current scheme in code does, i.e encode the subvol ID based on children of DHT, which is based on dht_subvol_cnt, which means indirectly the order of children seen in the graph.

I would further state, this change does not improve that limitation, rather it just changes the encoding to a single point.


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.


I would differ in the reasoning here, NFS clients store d_off returned on directory scans, hence it is possible that they come back with those d_off values post a graph switch and in this case it would be a fresh opendir and then seeking to the d_off provided (with all the subvol ID decoding etc.).

So in short, we are not immune to this.

Shyam
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel




[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux