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

[Vijay Bellur]

On Sun, Mar 19, 2017 at 10:14 AM, Amar Tumballi <atumball at redhat.com> wrote:

>
>
> On Thu, Mar 16, 2017 at 6:52 AM, Soumya Koduri <skoduri at redhat.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20170319/0a55d6de/attachment-0001.html>