Frank, see this thread on lkml - this should at least
get you going.
The changes should make it into 2.6.4 I think.
On Fri, 27 Feb 2004, Frank Hellmann wrote:
> 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.
> > -Eric
> > 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?
> >> Cheers,
> >> Frank...
> 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