Re: Xfs Access to block zero exception and system crash

[Sagar Borikar <sagar_borikar@xxxxxxxxxxxxxx>]

Eric Sandeen wrote:
> Sagar Borikar wrote:
>
>   
> > All the the copies are pending and file size in those directories is 
> > constant. It is not
> > increasing.
> >  And as the processes are in D state, the file system is marked as busy 
> > and I can't unmount
> > it.
> >     
>
> Understood.  It looks like you've deadlocked somewhere.  But, this is
> not the problem you are really trying to solve, right?  You just were
> trying to recreate the mips problem on x86?
>   
That's right. The intention behind testing on 2.6.24 was to check 
whether we can imitate
failure on x86 which is considered to be more robust. If we replicate 
the failure then
there could be some issue in XFS and if the test passes then we can back 
port this kernel
on MIPS ( Which any way I am doing with your patches ). But I faced 
similar deadlock on MIPS
with exceptions which I posted earlier.

> If you want, do a sysrq-t to get traces of all those cp's to see where
> they're stuck, but this probably isn't getting you much closer to
> solving the original problem.
>
>   
I'll keep you posted with it.
> (BTW: is this the exact same testcase that led to the block 0 access on
> mips which started this thread?)
>
> -Eric
>   
Ok. So initially our multi client iozone stress test used to fail. But 
as it took 2-3 days
to replicate the issue, I tried the test, standalone on MIPS and 
observed similar failures which
I used to get in multi client test. The test is exactly same what I do 
in mutli client
iozoen over network. Hence I came to conclusion that if we fix system to 
pass my test case
then we can try iozone test with that fix.  And now on x86 with 2.6.24, 
I am finding similar deadlock but
the system is responsive and there are no lockups or exceptions. Do you 
observe similar failures on x86
at your setup? Also do you think the issues which I am seeing on x86 and 
MIPS are coming from the
same sources?

Thanks
Sagar