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. -Amar > > Thanks, > Soumya > _______________________________________________ > Gluster-devel mailing list > [email protected] > http://lists.gluster.org/mailman/listinfo/gluster-devel > -- Amar Tumballi (amarts)
_______________________________________________ Gluster-devel mailing list [email protected] http://lists.gluster.org/mailman/listinfo/gluster-devel
