<div dir="ltr">As of now, signing happens only upon data modification. Metadata changes and xattr changes does not trigger signing.<div><br></div><div>For more information about gluster and its internals, you can look here &quot;<a href="https://gluster.readthedocs.org/en/latest/">https://gluster.readthedocs.org/en/latest/</a>&quot;.</div><div><br></div><div>Regards,</div><div>Raghavendra</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 25, 2016 at 10:28 AM, Ajil Abraham <span dir="ltr">&lt;<a href="mailto:ajil95.abraham@gmail.com" target="_blank">ajil95.abraham@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks FNU Raghavendra.  Does the signing happen only when the file data changes or even when extended attribute changes? <div><br></div><div>I am also trying to understand the Gluster internal data structures. Are there any materials for the same? Similarly for the translators, the way they are stacked on client &amp; server side, how control flows between them.  Can somebody please help?</div><span class="HOEnZb"><font color="#888888"><div><br></div></font></span><div><span class="HOEnZb"><font color="#888888">- Ajil</font></span><div><div class="h5"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 25, 2016 at 7:27 AM, FNU Raghavendra Manjunath <span dir="ltr">&lt;<a href="mailto:rabhat@redhat.com" target="_blank">rabhat@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Ajil,<div><br></div><div>Expiry policy tells the signer (Bit-rot Daemon) to wait for a specific period of time before signing a object.</div><div><br></div><div>Whenever a object is modified, a notification is sent to the signer by brick process (bit-rot-stub xlator sitting in the I/O path) upon getting a release (i.e. when all the fds of that object are closed). The expiry policy tells the signer to wait for some time (by default its 120 seconds) before signing that object. It is done because, suppose the signer starts signing (i.e. read the object + calculate the checksum + store the checksum) a object the object gets modified again, then a new notification has to be sent and again signer has to sign the object by calculating the checksum. Whereas if the signer waits for some time and receives a new notification on the same object when its waiting, then it can avoid signing for the first notification.</div><div><br></div><div>Venky, do you want to add anything more?</div><div><br></div><div>Regards,</div><div>Raghavendra</div><div><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Wed, Feb 24, 2016 at 12:28 AM, Ajil Abraham <span dir="ltr">&lt;<a href="mailto:ajil95.abraham@gmail.com" target="_blank">ajil95.abraham@gmail.com</a>&gt;</span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr">Hi,<div><br></div><div>I am a student interested in GlusterFS.  Trying to understand the design of GlusterFS. Came across the Bitrot design document in Google. There is a mention of expiry policy used to sign the files. I did not clearly understand what the expiry policy is.  Can somebody please help?</div><span><font color="#888888"><div><br></div><div>-Ajil</div></font></span></div>
<br></div></div>_______________________________________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.org</a><br>
<a href="http://www.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://www.gluster.org/mailman/listinfo/gluster-devel</a><br></blockquote></div><br></div>
</blockquote></div><br></div></div></div></div></div>
</blockquote></div><br></div>