Re: XFS corruption on ubuntu 2.6.27-9-server

[Eric Sandeen <sandeen@sandeen.net>]

George Barnett wrote:
> On 04/02/2009, at 12:46 PM, Eric Sandeen wrote:
> 
>>> bad version number 0x0 on inode 18046
>>> bad magic number 0x0 on inode 18047
>>> bad version number 0x0 on inode 18047
>>> bad directory block magic # 0 in block 0 for directory inode 18000
>> Interesting that all the bad magic numbers were 0... not sure what to
>> make of that, offhand, I'm afraid...
> 
> Oh dear.
> 
> I'm going to try moving the filesystem to ext3 to see if this  
> continues.  If it does, it would suggest a bug in the underlying  
> raid10 implementation or a problem with the disks, although they're  
> not reporting any errors [1].

one thing to note is that xfs is very good at detecting on-disk
corruption, not sure ext3 will be as good.  So ext3 may seem to run
finer, longer, even if there is an underlying problem.

> Is there any further debugging I can do before I start fresh?

well, it'd be great to have an isolated testcase, if you can reproduce
it succinctly.

Also I don't know what exact kernel ubuntu uses or what patches are in
it; you might try a stock upstream kernel w/ the same config,
2.6.27.$LATEST, and see if you continue to have problems.

-Eric

> George
> 
> 
> 1.  The hardware ecc recovered smartctl metric is /very/ high,  
> although I'm told this may be normal for samsung drives.  I cant think  
> of any way to confirm a disk problem without a CRC checking fs though.
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs