|
On Monday 01 December 2014 04:51 PM,
Raghavendra G wrote:
If a readdir on .snaps entered from a non root directory has to show the list of only those snapshots where the directory (or rather gfid of the directory) is present, then the way to achieve will be bit costly. When readdir comes on .snaps entered from a non root directory (say ls /dir/.snaps), following operations have to be performed 1) In a array we have the names of all the snapshots. So, do a nameless lookup on the gfid of /dir on all the snapshots 2) Based on which snapshots have sent success to the above lookup, build a new array or list of snapshots. 3) Then send the above new list as the readdir entries. But the above operation it costlier. Because, just to serve one readdir request we have to make a lookup on each snapshot (if there are 256 snapshots, then we have to make 256 lookup calls via network). One more thing is resource usage. As of now any snapshot will be initied (i.e. via gfapi a connection is established with the corresponding snapshot volume, which is equivalent to a mounted volume.) when that snapshot is accessed (from fops point of view a lookup comes on the snapshot entry, say "ls /dir/.snaps/snap1"). Now to serve readdir all the snapshots will be accessed and all the snapshots are initialized. This means there can be 256 instances of gfapi connections with each instance having its own inode table and other resources). After readdir if a snapshot is not accessed, so many resources of that snapshots will add up to the snap daemon's usage. With the above points in mind, I was thinking about different approaches to handle this situation. We need latest snapshot (and as per the patch, adjacent snapshots to handle restore) to resolve lookups coming on .snaps. Mainly for resolving the parent gfid so that we can look it up somewhere (if "ls /dir/.snaps is done, then lookup comes with parent gfid set to gfid of /dir and name set to ".snaps". But since /dir has not been looked up yet in snap daemon, it has to first resolve parent gfid for which it looks at latest snapshot). What we can do is, while sending lookup on .snaps (again, say "ls /dir/.snaps") within the dict add a key, which snapview-server can look for. That key is kinda hint from snapview-client to the snapview-server that the parent gfid of this particular lookup call exists and valid one. When snapview-server gets lookup as part of resolution from protocol/server on the parent gfid, it can look at the dict for the key. If the key is set, then simply return success to that lookup. With the above way we can handle many situations such as this: Entering .snaps from a directory which is created after taking the latest snapshot. Please provide feedback on the above approach (the hint being set in the dict). Regards, Raghavendra Bhat
|
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel
