On Sun, Mar 19, 2017 at 10:14 AM, Amar Tumballi <atumball@xxxxxxxxxx> wrote:
On Thu, Mar 16, 2017 at 6:52 AM, Soumya Koduri <skoduri@xxxxxxxxxx> wrote:Okay. But since self-heal and snapview-server (atleast) seem to be using gfapi, how can gfapi differentiate between these internal clients and other applications (like NFS/SMB)? I thought we need intelligence on server-side to identify such clients based on pid and then avoid updating timestamp sent by them.
On 03/16/2017 02:27 PM, Mohammed Rafi K C wrote:
On 03/15/2017 11:31 PM, Soumya Koduri wrote:
Hi Rafi,
I haven't thoroughly gone through design. But have few
comments/queries which I have posted inline for now .
On 02/28/2017 01:11 PM, Mohammed Rafi K C wrote:
Thanks for the reply , Comments are inline
On 02/28/2017 12:50 PM, Niels de Vos wrote:
On Tue, Feb 28, 2017 at 11:21:55AM +0530, Mohammed Rafi K C wrote:It is the top layer (master xlator) in client graph like fuse, gfapi,
Hi All,What do you mean with "top layer"? Is this on the Gluster client, or
We discussed the problem $subject in the mail thread [1]. Based on the
comments and suggestions I will summarize the design (Made as
points for
simplicity.)
1) As part of each fop, top layer will generate a time stamp and
pass it
to the down along with other param.
1.1) This will bring a dependency for NTP synced clients along
with
servers
does the time get inserted on the bricks?
nfs . My mistake I should have mentioned . Sorry for that.
These clients shouldn't include internal client processes like
rebalance, self-heal daemons right? IIUC from [1], we should avoid
changing times during rebalance and self-heals.
Also what about fops generated from the underlying layers -
getxattr/setxattr which may modify these time attributes?
Since the time stamps are appended from master xlators like fuse , we
will not have the timestamp for internal daemons as they don't have
master xlator loaded. internal fops won't generate new timestamp , even
if we are sending an internal fops from say dht, it will have only one
time genrated by fuse. So I think this is fine.
Very good point. Considering we should be using gfapi in future for most of the internal processes, this becomes more important. Should we just add it as argument to glfs_init() options? If you set a flag during init, the ctime xattr is not generated for the fops which otherwise generate and send them.
Most internal clients are recognized by their special PIDs (gf_special_pid_t) in various translators. We could store this PID information in a global location and use that to determine whether timestamp generation is needed. This way we will not be required to change any api signature for distinguishing internal clients.
Regards,
Vijay
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://lists.gluster.org/mailman/listinfo/gluster-devel
