Hello, I am playing around with the bitrot feature and have some questions: 1. when a file is created, the "trusted.bit-rot.signature? attribute seems only created approximatively 120 seconds after its creations (the cluster is idle and there is only one file living on it). Why ? Is there a way to make this attribute generated at the same time of the file creation ? 2. corrupting a file (adding a 0 locally on a brick) before the creation of the "trusted.bit-rot.signature? do not provide any warning: its signature is different than the 2 others copies on other bricks. Starting a scrub did not show up anything. I would think that Gluster compares signature between bricks for this particular use cases, but it seems the check is only local, so a file corrupted before it?s bitrot signature creation stay corrupted, and thus could be served to clients whith bad data ? Gluster 3.12.8 on Debian Stretch, bricks on ext4. Volume Name: vol1 Type: Replicate Volume ID: 85ccfaf2-5793-46f2-bd20-3f823b0a2232 Status: Started Snapshot Count: 0 Number of Bricks: 1 x 3 = 3 Transport-type: tcp Bricks: Brick1: gluster-01:/data/brick1 Brick2: gluster-02:/data/brick2 Brick3: gluster-03:/data/brick3 Options Reconfigured: storage.build-pgfid: on performance.client-io-threads: off nfs.disable: on transport.address-family: inet features.bitrot: on features.scrub: Active features.scrub-throttle: aggressive features.scrub-freq: hourly Cheers, C?dric
Hi Cedric, Any file is picked up for signing by the bitd process after the predetermined wait of 120 seconds. This default value is captured in the volume option 'features.expiry-time' and is configurable - in your case, it can be set to 0 or 1. Point 2 is correct. A file corrupted before the bitrot signature is generated will not be successfully detected by the scrubber. That would require admin/manual intervention to explicitly heal the corrupted file. -Sweta On 04/16/2018 10:42 PM, Cedric Lemarchand wrote:> Hello, > > I am playing around with the bitrot feature and have some questions: > > 1. when a file is created, the "trusted.bit-rot.signature? attribute > seems only created approximatively 120 seconds after its creations > (the cluster is idle and there is only one file living on it). Why ? > Is there a way to make this attribute generated at the same time of > the file creation ? > > 2. corrupting a file (adding a 0 locally on a brick) before the > creation of the "trusted.bit-rot.signature? do not provide any > warning: its signature is different than the 2 others copies on other > bricks. Starting a scrub did not show up anything. I would think that > Gluster compares signature between bricks for this particular use > cases, but it seems the check is only local, so a file corrupted > before it?s bitrot signature creation stay corrupted, and thus could > be served to clients whith bad data ? > > Gluster 3.12.8 on Debian Stretch, bricks on ext4. > > Volume Name: vol1 > Type: Replicate > Volume ID: 85ccfaf2-5793-46f2-bd20-3f823b0a2232 > Status: Started > Snapshot Count: 0 > Number of Bricks: 1 x 3 = 3 > Transport-type: tcp > Bricks: > Brick1: gluster-01:/data/brick1 > Brick2: gluster-02:/data/brick2 > Brick3: gluster-03:/data/brick3 > Options Reconfigured: > storage.build-pgfid: on > performance.client-io-threads: off > nfs.disable: on > transport.address-family: inet > features.bitrot: on > features.scrub: Active > features.scrub-throttle: aggressive > features.scrub-freq: hourly > > Cheers, > > C?dric > _______________________________________________ > Gluster-users mailing list > Gluster-users at gluster.org > http://lists.gluster.org/mailman/listinfo/gluster-users
Hi Sweta, Thanks, this drive me some more questions: 1. What is the reason of delaying signature creation ? 2. As a same file (replicated or dispersed) having different signature thought bricks is by definition an error, it would be good to triggered it during a scrub, or with a different tool. Is something like this planned ? Cheers ? C?dric Lemarchand> On 18 Apr 2018, at 07:53, Sweta Anandpara <sanandpa at redhat.com> wrote: > > Hi Cedric, > > Any file is picked up for signing by the bitd process after the predetermined wait of 120 seconds. This default value is captured in the volume option 'features.expiry-time' and is configurable - in your case, it can be set to 0 or 1. > > Point 2 is correct. A file corrupted before the bitrot signature is generated will not be successfully detected by the scrubber. That would require admin/manual intervention to explicitly heal the corrupted file. > > -Sweta > > On 04/16/2018 10:42 PM, Cedric Lemarchand wrote: >> Hello, >> >> I am playing around with the bitrot feature and have some questions: >> >> 1. when a file is created, the "trusted.bit-rot.signature? attribute >> seems only created approximatively 120 seconds after its creations >> (the cluster is idle and there is only one file living on it). Why ? >> Is there a way to make this attribute generated at the same time of >> the file creation ? >> >> 2. corrupting a file (adding a 0 locally on a brick) before the >> creation of the "trusted.bit-rot.signature? do not provide any >> warning: its signature is different than the 2 others copies on other >> bricks. Starting a scrub did not show up anything. I would think that >> Gluster compares signature between bricks for this particular use >> cases, but it seems the check is only local, so a file corrupted >> before it?s bitrot signature creation stay corrupted, and thus could >> be served to clients whith bad data ? >> >> Gluster 3.12.8 on Debian Stretch, bricks on ext4. >> >> Volume Name: vol1 >> Type: Replicate >> Volume ID: 85ccfaf2-5793-46f2-bd20-3f823b0a2232 >> Status: Started >> Snapshot Count: 0 >> Number of Bricks: 1 x 3 = 3 >> Transport-type: tcp >> Bricks: >> Brick1: gluster-01:/data/brick1 >> Brick2: gluster-02:/data/brick2 >> Brick3: gluster-03:/data/brick3 >> Options Reconfigured: >> storage.build-pgfid: on >> performance.client-io-threads: off >> nfs.disable: on >> transport.address-family: inet >> features.bitrot: on >> features.scrub: Active >> features.scrub-throttle: aggressive >> features.scrub-freq: hourly >> >> Cheers, >> >> C?dric >> _______________________________________________ >> Gluster-users mailing list >> Gluster-users at gluster.org >> http://lists.gluster.org/mailman/listinfo/gluster-users >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20180418/8388e1ed/attachment.html>