[Gluster-devel] Need help with bitrot

FNU Raghavendra Manjunath rabhat at redhat.com
Thu Feb 25 01:57:29 UTC 2016


Hi Ajil,

Expiry policy tells the signer (Bit-rot Daemon) to wait for a specific
period of time before signing a object.

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.

Venky, do you want to add anything more?

Regards,
Raghavendra



On Wed, Feb 24, 2016 at 12:28 AM, Ajil Abraham <ajil95.abraham at gmail.com>
wrote:

> Hi,
>
> 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?
>
> -Ajil
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20160224/f1563c09/attachment.html>


More information about the Gluster-devel mailing list