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,
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,
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:
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
As always: any help is highly appreciated!
Willi.Langenberger@xxxxxxxxxxxxx Fax: +43/1/31336/702
Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria