[Top] [All Lists]

Re: XFS on large block device problem

To: Eric Sandeen <sandeen@xxxxxxx>
Subject: Re: XFS on large block device problem
From: Frank Hellmann <frank@xxxxxxxxxxxxx>
Date: Fri, 27 Feb 2004 11:43:19 +0100
Cc: XFS List <linux-xfs@xxxxxxxxxxx>
In-reply-to: <1077830153.1091.44.camel@xxxxxxxxxxxxxxxxxxxxxx>
Organization: Optical Art Film- und Special-Effects GmbH
References: <403E33DA.2070509@xxxxxxxxxxxxx> <1077830153.1091.44.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225
Hi Eric!

Eric Sandeen wrote:
If you are able to re-mkfs the filesystem, can you try a mkfs
immediately followed by a repair, to see if the mkfs worked properly? I've been talking to someone else on 2.6.3 + xfs + lbd + md where mkfs
wasn't even able to get bits down to the disk properly.  This is just
userspace; if we can't do writes and have md put them in the right
place, we're in trouble.  stracing mkfs, I see pwrites of superblocks to
locations that never seem to make it to disk...  I'm tempted to blame
md, but I need to try to recreate here.

Anyway, can you try mkfs.xfs; xfs_repair?


I did a clean run of the mkfs.xfs and two runs of xfs_repair.

It seems that the xfs_repair doesn't like the filesystem that much.

I attached the output and strace.

I was wondering if using the other LVM methods would help here? I will give the dm stuff a try and let you know, if it's just dependend on md.



On Thu, 2004-02-26 at 11:58, Frank Hellmann wrote:


I just upgraded one of our linux boxes (Redhat 9 + usual 2.6 and glibc patches) to kernel 2.6.3 and wanted to try out the large block device support. First attemp, beware... :-)

I setup a md0 device consisting of four ~1.5TB large devices with mkraid /dev/md0 and a simple /etc/raidtab.

I had some issues makeing the filesystem on /dev/md0. mkfs.xfs complained about a non-clean md0 device and would not let me do anything with it.

Upgrading to xfs-progs 2.6.3 and mdadm 1.5 tools didn't change that.

First doing an mkfs.ext3, mounting and unmounting the device seems to cure that. At least after that I could mkfs.xfs it.

Unfortunatly restoring (tar not xfsrestore) some demo data back onto the drive I was getting a lot of xfs/kernel messages into the logfile. The tar process stopped with errors after about 200M of restore and the last files got corrupted. pdflush has high activity (~95%).

xfs_repair reports beside a lot of other problems a couple of:

primary/secondary superblock XX conflict - AG superblock geometry info
conflicts with filesystem geometry

which really makes me wonder, whats going on... See the attached files for further info. Unfortunatly I currently don't have any debugging tools on that machine...

Everything is peachy (with LBD), if I stay below the usual 2TB limits with the 2.6.3 kernel.

Am I missing anything for XFS LBD support? Any ideas?


Frank Hellmann          Optical Art GmbH           Waterloohain 7a
Digital Cinema          http://www.opticalart.de   22769 Hamburg
frank@xxxxxxxxxxxxx     Tel: ++49 40 5111051       Fax: ++49 40 43169199

Attachment: xfs_lbd_problems.tgz
Description: GNU Zip compressed data

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