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

[Soumya Koduri]

On 03/20/2017 08:53 AM, Vijay Bellur wrote:
>
>
> On Sun, Mar 19, 2017 at 10:14 AM, Amar Tumballi <atumball at redhat.com
> <mailto:atumball at redhat.com>> wrote:
>
>
>
>     On Thu, Mar 16, 2017 at 6:52 AM, Soumya Koduri <skoduri at redhat.com
>     <mailto: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.
>
+1. Changing API (even with symbol version) would result in some 
inconvenience for the existing applications. Additionally, if this 
support is made optional (via any option), it shall be easier to isolate 
these changes in gfapi/gluster code-path.

Thanks,
Soumya

> Regards,
> Vijay