On Sun, Mar 19, 2017 at 10:14 AM, Amar Tumballi <[email protected]> wrote:
> > > On Thu, Mar 16, 2017 at 6:52 AM, Soumya Koduri <[email protected]> wrote: > >> >> >> 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: >>>>>> >>>>>>> Hi All, >>>>>>> >>>>>>> >>>>>>> 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 >>>>>>> >>>>>> What do you mean with "top layer"? Is this on the Gluster client, or >>>>>> does the time get inserted on the bricks? >>>>>> >>>>> It is the top layer (master xlator) in client graph like fuse, gfapi, >>>>> 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. >>> >> >> 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. >> >> > 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 [email protected] http://lists.gluster.org/mailman/listinfo/gluster-devel
