On Tue, Mar 25, 2008 at 4:43 PM, Marc Bejarano <beej@xxxxxxxxxxxx> wrote:
...
> >thanks to you (and grant) for the pointer! will try that next.
>
> unfortunately, we have been unable to reproduce the corruption using
> disktest :( running for days ends up with no corruption. my
> colleague had already written a similar tool and wasn't able to
> reproduce the problem with it, either. i don't think this rules out
> a head positioning problem, though.
Agreed. Unfortunate that it's not reproducable with disktest. :(
> we can easily reproduce the issue using the server's intended
> workload with the intended configuration, but that isn't something we
> can give to seagate to reproduce in-house.
>
> having never played with blocktrace, i have no idea what it's
> capabilities are. can it be used to record not just the IOs, but
> also their timings? any other ideas? i'm at a loss for how to turn
> my reproducible test case into something i can send to seagate for
> investigation.
Yes and yes (I think). But by itself, it won't help since block
trace tools don't generally do any data validation. Perhaps put
some wrappers around the block replay script to put known data
on the disk and then validate the contents once the block replay
has completed.
You might also look at:
http://www.cse.unsw.edu.au/~jmr/iomkc.tar.gz
since it has a README on how to use block trace with their
Markov chain generator. I'm sure other places describe how
to use Blocktrace replay as well.
hth,
grant
> thanks,
> marc
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
