[Top] [All Lists]

Re: Corruption of in-memory data detected.

To: Marc Schmitt <schmitt@xxxxxxxxxxx>
Subject: Re: Corruption of in-memory data detected.
From: Steve Lord <lord@xxxxxxx>
Date: Thu, 25 Oct 2001 07:12:05 -0500
Cc: Steve Lord <lord@xxxxxxx>, Eric Sandeen <sandeen@xxxxxxx>, linux-xfs@xxxxxxxxxxx, florin@xxxxxxx
Comments: In-reply-to Marc Schmitt <schmitt@inf.ethz.ch> message dated "Thu, 25 Oct 2001 14:09:32 +0200."
References: <200110242032.f9OKWPk32359@jen.americas.sgi.com> <3BD800FC.6020005@inf.ethz.ch>
Sender: owner-linux-xfs@xxxxxxxxxxx
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.

I hope to have a 2.4.13 xfs patch out today, maybe we will have to
get you to try it.

Thanks for your patience on this one.


> Steve Lord wrote:
> > Yes, but the detection process may need some work - ext2 will probably
> > have radically different behavior on an error. It may throw up on the
> > filesystem, or you may have to run fsck afterwards to see what happened
> > to the fs.
> Hmm, using mke2fs 1.25 (with m set to 1), mongo runs a complete 
> benchmark over the 1.2TB:
> Filesystem           1k-blocks       Used Available  Use% Mounted on
> /dev/md0             1135510828        20 1123788584   1% /local
> After unmounting, I ran e2fsck:e2fsck 1.25 (20-Sep-2001)
> /dev/md0: clean, 11/293076992 files, 9177898/293055600 blocks
> Same steps as above with the current version of e2fsprogs on a RedHat 
> 7.1 system showed no different result (e2fsck 1.23, 15-Aug-2001 for EXT2 
> FS 0.5b, 95/08/09)
> Greetz
>       Marc

<Prev in Thread] Current Thread [Next in Thread>