On Thu, Aug 02 2007, Shawn Lewis wrote:
> On 8/2/07, Jens Axboe <jens.axboe_at_oracle.com> wrote:
> >
> > On Wed, Aug 01 2007, Shawn Lewis wrote:
> > > diff --git a/verify.c b/verify.c
> > > index 5bdfb76..fadf1c0 100644
> > > --- a/verify.c
> > > +++ b/verify.c
> > > @@ -349,7 +349,7 @@ int verify_io_u(struct thread_data *td,
> > > struct verify_header *hdr;
> > > unsigned int hdr_inc, hdr_num = 0;
> > > void *p;
> > > - int ret;
> > > + int ret = 0;
> > >
> > > if (td->o.verify == VERIFY_NULL || io_u->ddir != DDIR_READ)
> > > return 0;
> > > @@ -401,7 +401,7 @@ int verify_io_u(struct thread_data *td,
> > > hdr_num++;
> > > }
> > >
> > > - return 0;
> > > + return ret;
> > > }
> > >
> > > static void fill_meta(struct verify_header *hdr, struct thread_data
> > *td,
> >
> > Hmm, I think it's useful, but perhaps we also need an option to keep
> > going? It may be interesting to continue verifying and see if the rest
> > of the blocks are ok, or if there are other failures in that data set.
> > Something like a
> >
> > verify_failure_fatal
> >
> > or whatever, I'm not very good with names. If you have a better option
> > name, please tell me :-)
>
>
> Actually I'd rather continue if there is a verify failure but it looks like
> the original intention was to die, and it got lost somewhere. ret is now not
> used. Maybe we should just always continue?
Continue is what it does now. So I'm obviously fine with that behaviour,
as long as it's clearly noted that it failed (and the exit status shows
that).
-- Jens AxboeReceived on Thu Aug 02 2007 - 22:17:52 CEST
This archive was generated by hypermail 2.2.0 : Thu Aug 02 2007 - 22:30:01 CEST