On Mon, Apr 05, 2010 at 01:08:58PM +0800, jing zhang wrote: > > Before linux-2.6.32 is released, would you like tell me, how is ext4 tested? > Is tough testing able to catch all bugs? For one thing, we use the XFSQA (aka xfstests) test suite. I usually run the "quick" set of tests between each commit, and I run a much longer "auto" test suite before submitting a set of patches to Linus. For specific patches, we also like to be able to test it specifically. So often we'll create a small filesystem image and then see what the file system does with and without the patch. For example, if we're worried that a specific file system corruption will cause a BUG_ON, we'll create a small file system, corrupt it using the debugfs tool, and then demonstrate that without the patch, we get the BUG_ON. With the patch applied, the BUG_ON should go away. So the patch-specific tests are there so we can make sure the patch does what we think it should, and it fixes the problem it claims to fix. The XFSQA test suite is to there to make sure that we don't accidentally introduce bugs while trying to improve the file system. And of course, the final safeguard is patch review by others. This is where decent comments and making sure the code is maintainable is critically important. Since this takes other developer's time, especially senior developers like Eric and myself's time, which is rather valuable and hard to find, it's why patch submitters need shoulder more of the work in terms of refining patches and resubmitting new versions of the patches. - Ted P.S. Yes, Eric was absolutely correct. I wanted to know how much testing you had been doing on your patches before submitting them. At least few of your patches have caused me to wonder whether the patches had gone through sufficient testing. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
