xfs
[Top] [All Lists]

Re: xfs_repair crash

To: Thomas Graichen <graichen@xxxxxxxxxxxxx>, thomas.graichen@xxxxxxxxxxxxx, linux-xfs@xxxxxxxxxxx
Subject: Re: xfs_repair crash
From: "Nathan Scott" <nathans@xxxxxxxxxxxxxxxxxxxxxxxx>
Date: Sun, 20 Aug 2000 13:18:11 -0500
In-reply-to: Thomas Graichen <news-innominate.list.sgi.xfs@xxxxxxxxxxxxx> "xfs_repair crash" (Aug 19, 11:28pm)
References: <news2mail-8nm1vd$pci$1@xxxxxxxxxxxxxxxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
hi Thomas,

On Aug 19, 11:28pm, Thomas Graichen wrote:
> Subject: xfs_repair crash
> yet another one :-)
> 
> ok - with the old mkfs.xfs i was able to build xfs filesystems which
> were mountable and thus i was able to start running a system here at
> home completely on xfs (/ & /home) - works fine so far - even the
> shutdown now works (even with the code before the commit yester-
> day) ... ok i also have a small ext2 system on the disk too into

I have made one subsequent change to libxfs - everyone using a
recent mkfs should refresh their source tree and rebuild (both
libxfs and mkfs subdirs at least).

> which i might boot to check the xfs filesystems with xfs_repair
> ... this is what i got with that:
> 
> ...
> Phase 6 - check inode connectivity...
>         - resetting contents of realtime bitmap and summary inodes
>         - ensuring existence of lost+found directory
> xfs_repair: xfs_dir2_data.c:147: xfs_dir2_data_check: Assertion `i < ((( 0) 
> == 1) ? (btp->count) : ((sizeof((btp->count)) == 8) ? 
> ((typeof((btp->count)))(__fswab64((__u64)(btp->count)))) : 
> ((sizeof((btp->count)) == 4) ? 
> ((typeof((btp->count)))(__fswab32((__u32)(btp->count)))) : 
> ((sizeof((btp->count)) == 2) ? 
> ((typeof((btp->count)))(__fswab16((__u16)(btp->count)))) : ((btp->count))))) 
> )' failed.
> Aborted (core dumped)

I have just managed to reproduce this locally ... I'll look into
it further once I get in tomorrow.

One point to note is that assert's weren't enabled in the old
sim/xfs_repair code, and now are (perhaps they shouldn't be, for
repair).  At the stage where its dying though I wouldn't expect
it to, so thats probably not of much interest.

> an old xfs_repair works - so looks like also here is a small problem
> with the non-sim code - a rerun of xfs_repair after such a crash of
> it resulted in a growing nomber of
> 

This isn't surprising considering the initial repair was half-way
through creating the lost+found subdir when it died.  It would be
a good idea to use the -n option to the new xfs_repair until I
sort this out.

thanks.

-- 
Nathan

<Prev in Thread] Current Thread [Next in Thread>
  • xfs_repair crash, Thomas Graichen
    • Message not available
      • Re: xfs_repair crash, Nathan Scott <=