Seems that xfs_repair isn't very robust -- it doesn't even detect
the problem on my disk that causes xfsdump to knock my rootfs offline.
> -----Original Message-----
> From: linux-xfs-bounce@xxxxxxxxxxx
> [mailto:linux-xfs-bounce@xxxxxxxxxxx] On Behalf Of Russell G. Howe
> Sent: February 23, 2003 12:13a
> To: linux-xfs@xxxxxxxxxxx
> Subject: xfs_repair unable to repair a corrupt filesystem
> I'm having some problems with /var on my machine. The machine
> itself is
> rather unstable and hangs every few days, but I don't think that is
> What does concern XFS is the data corruption I experience after such a
> hard lockup (Alt+SysRq+B won't reboot the box, no HDD activity, etc).
> /var has had at least some corruption for the past week or so which I
> haven't had chance to fix. I took the opportunity just now after the
> latest hang (which has hosed /home). I'll post a seperate
> message about
> the /home problem singe it seems to be a seperate issue.
> xfs_repair on /var appeared to fix at least some things, but
> there were
> clearly still errors. I re-ran xfs_repair and got this output:
The output appears identical no matter how many times I run xfs_repair.
I'm using XFS from CVS, sometime around the 19th Dec (that is the date
of compilation, and I update just before I compile). It's based on
2.4.20. Is this too old to be of use as a bug report? I am able and
willing to build a more up to date release of XFS if need be.
xfs_repair is from the Debian (unstable) package, and reports its
version as 2.3.11
I can mount /var, but all those xfs_repair errors make me rather
suspicious about using it.
Most errors appear to be centred around one large (700Mbish) file, which
I don't mind losing.
Russell Howe | Why be just another cog in the machine,
rhowe@xxxxxxxxxx | when you can be the spanner in the works?