Re: Good stress test for UBIFS?

[David Jander <david.jander@protonic.nl>]

On Monday 28 December 2009 11:40:43 am Adrian Hunter wrote:
>[...]
> Generally we test with debugging checks turned on because they will spot an
> error the instant it happens.  On the other hand, you must also test the
>  actual configuration you will deploy.
> 
> There are two approaches.  We use both of them.  They are:
> 
> 1. Set up a desktop machine with your kernel and test on nandsim.  This has
>  the advantage that it can do very many more operations than a small
>  device.
> 
> You can simulate power-off-recovery by using UBIFS "failure mode".  Set
>  UBIFS debugging module parameter debug_tsts to 4.  There is a script I
>  have used for that below.

Yes, but I did not consider this option, because it is a completely different 
processor architecture (little-endian vs. big-endian), also it won't test the 
hardware-driver, nor the nand-chip and interface which can potentially also be 
(part of) the problem. Here I am trying to reproduce a situation that has 
already occurred a few times in "real life", and I need to be sure it won't 
happen ever again with the latest ubi/ubifs.

> 2. Run tests on the device.  There are tests in mtd-utils/tests/fs-tests
>  but LTP's fsstress is good for stressing the file system during
>  power-off-recovery testing.

Thanks a lot. I will try fsstress.
I had already written my own test script, mimicking some suspicious scenarios, 
in the hope it would reproduce what had happend on three of our boards 
(corrupt fs), and eventually succeded, but it took several days running.
Now I am re-running the test with latest UBI/UBIFS to see if it's gone.
Hopefully fsstress will yield results more quickly.

Best regards,

-- 
David Jander
Protonic Holland.