On 03/20/2017 08:53 AM, Vijay Bellur wrote:

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

    On Thu, Mar 16, 2017 at 6:52 AM, Soumya Koduri <skod...@redhat.com
    <mailto:skod...@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

                            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

                        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

                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.


Gluster-devel mailing list

Reply via email to