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 <[email protected]> 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 > [email protected] > http://www.gluster.org/mailman/listinfo/gluster-devel >
_______________________________________________ Gluster-devel mailing list [email protected] http://www.gluster.org/mailman/listinfo/gluster-devel
