xfs
[Top] [All Lists]

XFS-filesystem corrupted by defragmentation

To: xfs@xxxxxxxxxxx
Subject: XFS-filesystem corrupted by defragmentation
From: Bernhard Gschaider <bgschaid_lists@xxxxxxxxx>
Date: Tue, 13 Apr 2010 14:10:02 +0200
Organization: ICE Stroemungsforschung
User-agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.5-b29 (linux)
Hi!

I'm asking here because I've been referred here fro the CentOS-mailing
list (for the full story see
http://www.pubbs.net/201004/centos/17112-centos-performance-problems-with-xfs-on-centos-54.html
and 
http://www.pubbs.net/201004/centos/24542-centos-xfs-filesystem-corrupted-by-defragmentation-was-performance-problems-with-xfs-on-centos-54.html
the following stuff is a summary of this)

It was suggested to me that the source of my performance problems might
be the fragmentation of the XFS-system. I tested for fragmentation and
got 

xfs_db> frag
actual 6349355, ideal 4865683, fragmentation factor 23.37%

Before I'd try to defragment my whole filesystem I figured "Let's try
it on some file". 

So I did

> xfs_bmap /raid/Temp/someDiskimage.iso
[output shows 101 extents and 1 hole]

Then I defragmented the file
> xfs_fsr /raid/Temp/someDiskimage.iso
extents before:101 after:3 DONE

> xfs_bmap /raid/Temp/someDiskimage.iso
[output shows 3 extents and 1 hole]

and now comes the bummer: i wanted to check the fragmentation of the
whole filesystem (just for checking):

> xfs_db -r /dev/mapper/VolGroup00-LogVol04
xfs_db: unexpected XFS SB magic number 0x00000000
xfs_db: read failed: Invalid argument
xfs_db: data size check failed
cache_node_purge: refcount was 1, not zero (node=0x2a25c20)
xfs_db: cannot read root inode (22)

THAT output was definitly not there when I did this the last time and
therefor the new fragmentation does not make me happy either

xfs_db> frag
actual 0, ideal 0, fragmentation factor 0.00%

The file-system is still mounted and working and I don't dare to do
anything about it (am in a mild state of panic) because I think it
might not come back if I do.

Any suggestions most welcome (am googling myself before I do anything
about it).

I swear to god: I did not do anything else with the xfs_*-commands
than the stuff mentioned above

As far as I understood from other places the first thing to do is "try
to get the incore copy of the XFS superblock flushed out" before
proceeding (must find out how to do that). How would you suggest to
proceed from that? If defragmenting one file messes things up this
badly how safe is defragmentation in general?

Thanks for your time
Bernhard

Info about my system. Tell me if you need more info:

My system is a CentOS 5.4 (which is equivalent to a RHEL 5.4) which
means kernel 2.6.18 (64bit. Unmodified Xen-Kernel). xfs_db -V reports
"xfs_db version 2.9.4"

Memory on the system is 4Gig (2 DualCore Xenons). The filesystem is
3.5 TB of which 740 Gig are used. Which is the maximum amount used
during the one year that the filesystem is being used (that is why the
high fragmentation amazes me) The filesystem is on a LVM-Volume which
sits on a RAID 5 (Hardware RAID) drive.

% xfs_info  /raid
meta-data=/dev/VolGroup00/LogVol05 isize=256    agcount=32, agsize=29434880 blks
         =                       sectsz=512   attr=0
data     =                       bsize=4096   blocks=941916160, imaxpct=25
         =                       sunit=0      swidth=0 blks, unwritten=1
naming   =version 2              bsize=4096  
log      =internal               bsize=4096   blocks=32768, version=1
         =                       sectsz=512   sunit=0 blks, lazy-count=0
realtime =none                   extsz=4096   blocks=0, rtextents=0


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