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@xxxxxxxxx> 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@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
