I would recommend the following tests. 1) The tests in our regression tests 2) Creating data set of many files (of different sizes) and then enabling bit-rot on the volume. 3) scrubber throttling 4) Tests such as open + write + close and again open + write + close (i.e. before the bit-rot daemon can sign the file the file is modified again) 5) Exceed the lru size of the inode table. (So that inodes are forgotten). The next lookup of the file should properly populate all the necessary details into the inode context. 6) Simulating the corruption by directly changing a file in the backend and checking if its marked as bad or not. (Also access to such bad files should give EIO) 7) Change scrubbing intervals and check if it kicks in correctly.
Kotresh, Can you please add any other tests that should be considered? Regards, Raghavendra On Fri, Sep 2, 2016 at 2:25 PM, Pranith Kumar Karampuri <pkara...@redhat.com > wrote: > > > On Fri, Sep 2, 2016 at 11:39 PM, Pranith Kumar Karampuri < > pkara...@redhat.com> wrote: > >> hi, >> Did you get a chance to decide on the tests that need to be done >> before doing a release for Bitrot component? Could you let me know who will >> be providing with the list? >> >> I can update it at https://public.pad.fsfe.org/p/ >> gluster-component-release-checklist >> >> -- >> Pranith >> > Sorry, forgot to add 'Aravinda & Pranith' >
_______________________________________________ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
