On Monday 01 December 2014 05:36 PM,
Raghavendra Bhat wrote:
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.
From a NFS mount moint, if we do 'ls /dir/.snaps/', NFS client
will send a stat on all the entries and only after this it returns
to the application. This will also initiate gfapi for all the
snapshots right?
Thanks,
Vijay
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
|
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://supercolony.gluster.org/mailman/listinfo/gluster-devel
