Ah ha, now thats a good idea - of course I still think its the md
code, but at least we have a chance of catching it now.
Thanks
Steve
> Hi Steve
>
> Steve Lord [lord@xxxxxxx] wrote:
> >
> > OK, so the next possibility is the fact that xfs is setting the block
> > size of the device to 512 bytes and that pushes some calculations over.
> > I am experimenting with some new code in 2.4.13 which removes this
> > chunk of code, the next thing to try may be this, I am running md
> > tests on it this morning and so far it looks good, but I do not
> > have access to enough disk to test for the size overflow.
>
> Maybe you can use a 1.2TB hole loop mounted.
>
>
> dd if=/dev/null of=loopfile bs=1024 seek=1288490188
> mkfs.xfs loopfile
> mount -o loop loopfile /xxx/
>
>
> I made this, and copy the kernel sources into /xxx/ and got the same errors
> like Marc:
>
> Oct 25 14:54:18 donner kernel: xfs_force_shutdown(loop(7,0),0x8) called from
> line 1020 of file xfs_trans.c. Return address = 0xc01b4d15
> Oct 25 14:54:18 donner kernel: Corruption of in-memory data detected. Shutti
> ng down filesystem: loop(7,0)
>
>
> With 0.98TB no errors occured except one time my machine run out of memory.
>
> Kernel is 2.4.13-pre6-xfs-20011023 + preempt patch.
>
>
> utz
|