On Thu, Apr 22, 2010 at 7:22 PM, Martin Bligh <[email protected]> wrote: > On Thu, Apr 22, 2010 at 11:54 AM, Akshay Lal <[email protected]> wrote: >> Well previously, when the fsck ran on an unmounted file system and the file >> system was dirty/corrupted in anyway, the fsck would throw an error (but fix >> the file system '-fy'). This error would get logged in the >> console/tests-specific log as an 'ERROR', but the overall test would pass. >> Thats not really very non-intuitive and not correct (either) since you >> ideally want the file system in a clean state after all the tests run. >> Explicitly stating that a failure in an fsck run results in a test failure >> seems like the right approach - I think. > > That seems odd. I'd think the test level error handler would convert > it. Greg - do you recall from refactoring that code? > > I'm suspicious of throwing a TestError from something that can > be run from outside of a test. >
I suggested that Akshay put this here. But if thats wrong, we need to look closer to figure out where it goes. What calls this code? The only caller I see is partition.cleanup_after_test() which is called by partition.run_test_on_partition after job.run_test() is finished but still within the context of job.run_group(). Is it crazy of me to think that filesystem tests should be calling this directly within the context of a test if they want to depend on the error being flagged as a test problem. Which either means that partition.run_test_on_partition probably needs to be reworked to make sure the fsck happens within run_test context or that the tests using it should explicitly call partition.fsck themselves when they want the fsck result to change the test outcome. -gps _______________________________________________ Autotest mailing list [email protected] http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
