On 03/20/2017 08:53 AM, Vijay Bellur wrote:
On Sun, Mar 19, 2017 at 10:14 AM, Amar Tumballi <atumball@xxxxxxxxxx
<mailto:atumball@xxxxxxxxxx>> wrote:
On Thu, Mar 16, 2017 at 6:52 AM, Soumya Koduri <skoduri@xxxxxxxxxx
<mailto:skoduri@xxxxxxxxxx>> 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
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-devel
