[Gluster-devel] Consistent time attributes (ctime, atime and mtime) across replica set and distribution set

Soumya Koduri skoduri at redhat.com
Thu Mar 16 10:52:42 UTC 2017



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.

Thanks,
Soumya


More information about the Gluster-devel mailing list