xfs
[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 13:24:52 -0500
Cc: Steve Lord <lord@xxxxxxx>, Eric Sandeen <sandeen@xxxxxxx>, linux-xfs@xxxxxxxxxxx, florin@xxxxxxx
In-reply-to: Message from Marc Schmitt <schmitt@inf.ethz.ch> of "Thu, 25 Oct 2001 14:09:32 +0200." <3BD800FC.6020005@inf.ethz.ch>
Sender: owner-linux-xfs@xxxxxxxxxxx
Just in case I did not make it obvious, we think the fix for this is a
new mkfs. The old one was generating inconsistent superblocks for
filesystems above 1 Tbyte. The only folks affected by this probably
had filesystems which would take down the machine if you used them
anyway. So if your filesystem is working for you using the old mkfs
then there is no need to do anything except upgrade the commands.

If you made a filesystem of greater than 1 Tbyte using

        mkfs -t xfs -i size=512 .....

then you should also not be affected.

Steve


> 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>