<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Mar 19, 2017 at 10:14 AM, Amar Tumballi <span dir="ltr"><<a href="mailto:atumball@redhat.com" target="_blank">atumball@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="gmail-h5">On Thu, Mar 16, 2017 at 6:52 AM, Soumya Koduri <span dir="ltr"><<a href="mailto:skoduri@redhat.com" target="_blank">skoduri@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-m_8772489636240198804HOEnZb"><div class="gmail-m_8772489636240198804h5"><br>
<br>
On 03/16/2017 02:27 PM, Mohammed Rafi K C wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
On 03/15/2017 11:31 PM, Soumya Koduri wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Hi Rafi,<br>
<br>
I haven't thoroughly gone through design. But have few<br>
comments/queries which I have posted inline for now .<br>
<br>
On 02/28/2017 01:11 PM, Mohammed Rafi K C wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Thanks for the reply , Comments are inline<br>
<br>
<br>
<br>
On 02/28/2017 12:50 PM, Niels de Vos wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On Tue, Feb 28, 2017 at 11:21:55AM +0530, Mohammed Rafi K C wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Hi All,<br>
<br>
<br>
We discussed the problem $subject in the mail thread [1]. Based on the<br>
comments and suggestions I will summarize the design (Made as<br>
points for<br>
simplicity.)<br>
<br>
<br>
1) As part of each fop, top layer will generate a time stamp and<br>
pass it<br>
to the down along with other param.<br>
<br>
1.1) This will bring a dependency for NTP synced clients along<br>
with<br>
servers<br>
</blockquote>
What do you mean with "top layer"? Is this on the Gluster client, or<br>
does the time get inserted on the bricks?<br>
</blockquote>
It is the top layer (master xlator) in client graph like fuse, gfapi,<br>
nfs . My mistake I should have mentioned . Sorry for that.<br>
</blockquote>
<br>
These clients shouldn't include internal client processes like<br>
rebalance, self-heal daemons right? IIUC from [1], we should avoid<br>
changing times during rebalance and self-heals.<br>
<br>
Also what about fops generated from the underlying layers -<br>
getxattr/setxattr which may modify these time attributes?<br>
</blockquote>
<br>
Since the time stamps are appended from master xlators like fuse , we<br>
will not have the timestamp for internal daemons as they don't have<br>
master xlator loaded. internal fops won't generate new timestamp , even<br>
if we are sending an internal fops from say dht, it will have only one<br>
time genrated by fuse. So I think this is fine.<br>
</blockquote>
<br></div></div>
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.<div class="gmail-m_8772489636240198804HOEnZb"><div class="gmail-m_8772489636240198804h5"><br></div></div></blockquote><div><br></div></div></div><div>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.<br><br></div><div><br></div></div></div></div></blockquote><div><br></div><div><br></div><div>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.</div><div><br></div><div>Regards,</div><div>Vijay</div></div></div></div>