SCIENTIFIC-LINUX-USERS Archives

November 2009

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender:
Mailling list for Scientific Linux users worldwide <[log in to unmask]>
Date:
Fri, 27 Nov 2009 17:56:49 +0100
MIME-version:
1.0 (Apple Message framework v936)
Reply-To:
Stephan Wiesand <[log in to unmask]>
Content-type:
text/plain; delsp=yes; format=flowed; charset=US-ASCII
Subject:
From:
Stephan Wiesand <[log in to unmask]>
In-Reply-To:
Content-transfer-encoding:
7BIT
Comments:
Parts/Attachments:
text/plain (41 lines)
On Nov 27, 2009, at 17:28, Zhi-Wei Lu wrote:

> Jon Peatfield wrote:
>> On Fri, 27 Nov 2009, Jon Peatfield wrote:
>>
>>> On wednesday morning we updated most of our sl53 machines to the
>>> current 2.6.18-164.6.1.el5 kernel.
>>>
>>> Since then we have had two machines (both x86_64 of course) using  
>>> xfs
>>> report xfs corruption problems, e.g. on one of the machines today:
>>>
>>> Nov 27 11:57:40 yotei kernel: Filesystem "md0": corrupt dinode
>>> 1073743441, (btree extents).  Unmount and run xfs_repair.
>> <snip>
>>
>> I should have mentioned that this is xfs on top of a raid-5 md (both
>> affected machines are set up this way), but in any case it seems that
>> https://bugzilla.redhat.com/show_bug.cgi?id=512552 may be relevant so
>> I'm about to try the test kernel that is mentioned at the end of  
>> that bz.
>>
>> -- Jon
> I have experienced the xfs corruption problem on CentOS 5.4 using  
> the xfs kernel module packaged from the RHEL kernel source,  
> replacing the default xfs.ko with previous version of CentOS xfs.ko  
> (non RHEL) kernel module.  xfs file system worked just fine.


All this sounds scary. We've been running a few XFS filesystems with  
TUVs module since 164.2.1 was in testing, and a few dozen with 164.6.1  
for more than two weeks now. All without any problem, but most have  
not seen significant stress yet. We're not using md though, and the  
filesystems are not exported through NFS.

-- 
Stephan Wiesand
   DESY - DV -
   Platanenallee 6
   15738 Zeuthen, Germany

ATOM RSS1 RSS2