Hm, looks like log code error handling in general still needs some
scrutiny... I have to work my way out from under some internal
deadlines, and then I can start to look at this.
At first glance, it seems that we should not be returning -ENOMEM
anywhere in xfs_log_recover.c, XFS always expects to deal with + errors
internally. On the other hand, (again after just a quick glance) it
seems like some functions return block numbers and/or positive error
messages, not sure how the caller can distinguish between the two.
-Eric
On Tue, 2002-05-07 at 10:16, Ragnar Kjørstad wrote:
> On Tue, May 07, 2002 at 04:03:42PM +0200, Willi Langenberger wrote:
> > If "xlog_find_verify_log_record" returns -1, it jumps over the
> > assignment "*blk_no = last_blk" and returns "error" (which, in this
> > case is -1). So we have the case that "xlog_find_zeroed" returns -1,
> > in spite of the fact that *blk_no is _not_ set. But, according to the
> > comment of the function:
> >
> > * Return:
> > * 0 => the log is completely written to
> > * -1 => use *blk_no as the first block of the log
> > * >0 => error has occurred
> > */
>
> Yes, xlog_find_verify_log_record return negative numbers for errors (at
> least in some cases), and xlog_find_zeroed is supposed to return
> possitive numbers for errors, but passes on the value from
> xlog_find_verify_log_record. Clearly something fishy is going on :)
>
>
>
> --
> Ragnar Kjørstad
> Big Storage
--
Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs
sandeen@xxxxxxx SGI, Inc.
|