xfs
[Top] [All Lists]

Re: corrupt xfs filesystem -- xfs_repair dumps core

To: linux-xfs@xxxxxxxxxxx
Subject: Re: corrupt xfs filesystem -- xfs_repair dumps core
From: Willi Langenberger <wlang@xxxxxxxxxxxxx>
Date: Wed, 24 Apr 2002 16:15:02 +0200
In-reply-to: <15558.37214.558780.264419@slime.wu-wien.ac.at>
References: <15557.36194.760672.792045@slime.wu-wien.ac.at> <20020424082748.L63455@wobbly.melbourne.sgi.com> <15558.37214.558780.264419@slime.wu-wien.ac.at>
Reply-to: Willi.Langenberger@xxxxxxxxxxxxx
Sender: owner-linux-xfs@xxxxxxxxxxx
Hi all!

According to Willi Langenberger:
> According to Nathan Scott:
> > > Then, we upgraded the xfsprogs to 2.0.3, an now we get a core dump:
> > > 
> > >   # /sbin/xfs_repair /dev/sdb
> > >   Phase 1 - find and verify superblock...
> > >   Phase 2 - using internal log
> > >           - zero log...
> > >   xfs_repair: xfs_log_recover.c:159: xlog_find_verify_log_record: 
> > > Assertion `start_blk != 0 || *last_blk != start_blk' failed.
> > >   Aborted (core dumped)

I tried to debug xfs_repair (xfsprogs 2.0.3) to find out what is
going on, but i need help...

Function xlog_find_zeroed at xfs_log_recover.c:

        /*
         * We search for any instances of cycle number 0 that occur before
         * our current estimate of the head.  What we're trying to detect is
         *        1 ... | 0 | 1 | 0...
         *                       ^ binary search ends here
         */
        new_blk = xlog_find_verify_cycle(log, start_blk,
                                         (int)num_scan_bblks, 0);
        if (new_blk != -1)
                last_blk = new_blk;

        /*
         * Potentially backup over partial log record write.  We don't need
         * to search the end of the log because we know it is zero.
         */
        if ((error = xlog_find_verify_log_record(log, start_blk,
                                &last_blk, 0)))
            goto bp_err;

start_blk is zero and xlog_find_verify_cycle returns also zero for
new_blk  ==> that means, that xlog_find_verify_log_record is called
with start_blk=0 and last_blk=0 (last_blk is copied from new_blk).

However, this triggers the assertion in xlog_find_verify_log_record:

xlog_find_verify_log_record(xlog_t      *log,
                            xfs_daddr_t start_blk,
                            xfs_daddr_t *last_blk,
                            int         extra_bblks)
{
    xfs_daddr_t         i;
    xfs_buf_t           *bp;
    char                *buf        = NULL;
    xlog_rec_header_t   *head       = NULL;
    int                 error       = 0;
    int                 smallmem    = 0;
    int                 num_blks    = *last_blk - start_blk;

    ASSERT(start_blk != 0 || *last_blk != start_blk);

Can anybody say, what is the right thing to do? Should i ignore the
ASSERT? Or should i dive into xlog_find_verify_cycle, to find out, why
it returns 0 to new_blk? Or is there a way to completely skip the
``check partially zeroed log'' section in xlog_find_zeroed (i'd
happily forget the last changes, if i can access the filesystem
again...)

As always: any help is highly appreciated!


Thanks,


\wlang{}

-- 
Willi.Langenberger@xxxxxxxxxxxxx                 Fax: +43/1/31336/702
Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria


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