new barrier warnings in 2.6.29-rc1

new barrier warnings in 2.6.29-rc1

[Christoph Hellwig]

Whever a filesystem submits a bio with the barrier flag set but
the underlying hardware doesn't support it we now get errors in
the form of:

[ 3046.442629] end_request: I/O error, dev vdb, sector 0

since commit a7384677b2f4cd40948fd7ce024ba5e1821444ba which removed
the early check on the queue capabilities in __make_request.  I
think this message is pretty annoying and confusing for the user
as the filesystems already have more descriptive warnings, e.g. for
XFS:

[ 3046.455478] Filesystem "vdb": Disabling barriers, trial barrier write failed

Re: new barrier warnings in 2.6.29-rc1

[Tejun Heo]

(cc'ing Jens)
Hello,

Christoph Hellwig wrote:
> Whever a filesystem submits a bio with the barrier flag set but
> the underlying hardware doesn't support it we now get errors in
> the form of:
> 
> [ 3046.442629] end_request: I/O error, dev vdb, sector 0
> 
> since commit a7384677b2f4cd40948fd7ce024ba5e1821444ba which removed
> the early check on the queue capabilities in __make_request.  I
> think this message is pretty annoying and confusing for the user
> as the filesystems already have more descriptive warnings, e.g. for
> XFS:
> 
> [ 3046.455478] Filesystem "vdb": Disabling barriers, trial barrier write failed

I think the right thing to do is setting REQ_QUIET on the trial
barrier request.

Thanks.

-- 
tejun

Re: new barrier warnings in 2.6.29-rc1

[Jens Axboe]

On Tue, Jan 13 2009, Tejun Heo wrote:
> (cc'ing Jens)
> Hello,
> 
> Christoph Hellwig wrote:
> > Whever a filesystem submits a bio with the barrier flag set but
> > the underlying hardware doesn't support it we now get errors in
> > the form of:
> > 
> > [ 3046.442629] end_request: I/O error, dev vdb, sector 0
> > 
> > since commit a7384677b2f4cd40948fd7ce024ba5e1821444ba which removed
> > the early check on the queue capabilities in __make_request.  I
> > think this message is pretty annoying and confusing for the user
> > as the filesystems already have more descriptive warnings, e.g. for
> > XFS:
> > 
> > [ 3046.455478] Filesystem "vdb": Disabling barriers, trial barrier write failed
> 
> I think the right thing to do is setting REQ_QUIET on the trial
> barrier request.

It would surely work, but XFS doesn't really have a way to do that. Then
we would have to add a bio quiet flag and inherit that.

I kind of liked the old behaviour. What about something like the below?

diff --git a/block/blk-core.c b/block/blk-core.c
index a824e49..eddba4a 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -1448,6 +1448,11 @@ static inline void __generic_make_request(struct bio *bio)
 			err = -EOPNOTSUPP;
 			goto end_io;
 		}
+		if (bio_barrier(bio) && bio_has_data(bio) &&
+		    (q->next_ordered == QUEUE_ORDERED_NONE)) {
+			err = -EOPNOTSUPP;
+			goto end_io;
+		}
 
 		ret = q->make_request_fn(q, bio);
 	} while (ret);

-- 
Jens Axboe

Re: new barrier warnings in 2.6.29-rc1

[Tejun Heo]

Hello, Jens.

Jens Axboe wrote:
> On Tue, Jan 13 2009, Tejun Heo wrote:
>> I think the right thing to do is setting REQ_QUIET on the trial
>> barrier request.
> 
> It would surely work, but XFS doesn't really have a way to do that. Then
> we would have to add a bio quiet flag and inherit that.
> 
> I kind of liked the old behaviour. What about something like the below?
> 
> diff --git a/block/blk-core.c b/block/blk-core.c
> index a824e49..eddba4a 100644
> --- a/block/blk-core.c
> +++ b/block/blk-core.c
> @@ -1448,6 +1448,11 @@ static inline void __generic_make_request(struct bio *bio)
>  			err = -EOPNOTSUPP;
>  			goto end_io;
>  		}
> +		if (bio_barrier(bio) && bio_has_data(bio) &&
> +		    (q->next_ordered == QUEUE_ORDERED_NONE)) {
> +			err = -EOPNOTSUPP;
> +			goto end_io;
> +		}
>  
>  		ret = q->make_request_fn(q, bio);
>  	} while (ret);

I have no objection against it.  I kind of like having single test
point but it's a corner case anyway so no biggie.

Thanks.

-- 
tejun

Re: new barrier warnings in 2.6.29-rc1

[Jens Axboe]

On Tue, Jan 13 2009, Tejun Heo wrote:
> Hello, Jens.
> 
> Jens Axboe wrote:
> > On Tue, Jan 13 2009, Tejun Heo wrote:
> >> I think the right thing to do is setting REQ_QUIET on the trial
> >> barrier request.
> > 
> > It would surely work, but XFS doesn't really have a way to do that. Then
> > we would have to add a bio quiet flag and inherit that.
> > 
> > I kind of liked the old behaviour. What about something like the below?
> > 
> > diff --git a/block/blk-core.c b/block/blk-core.c
> > index a824e49..eddba4a 100644
> > --- a/block/blk-core.c
> > +++ b/block/blk-core.c
> > @@ -1448,6 +1448,11 @@ static inline void __generic_make_request(struct bio *bio)
> >  			err = -EOPNOTSUPP;
> >  			goto end_io;
> >  		}
> > +		if (bio_barrier(bio) && bio_has_data(bio) &&
> > +		    (q->next_ordered == QUEUE_ORDERED_NONE)) {
> > +			err = -EOPNOTSUPP;
> > +			goto end_io;
> > +		}
> >  
> >  		ret = q->make_request_fn(q, bio);
> >  	} while (ret);
> 
> I have no objection against it.  I kind of like having single test
> point but it's a corner case anyway so no biggie.

I agree, but it's a lot better than having to fiddle around with every
spot that wants to do a barrier probe. I'll merge it up for 2.6.29.
Christoph, can you double check that it gets rid of your warning and
still catches the barrier disable?

-- 
Jens Axboe

Re: new barrier warnings in 2.6.29-rc1

[Christoph Hellwig]

I still see the warnings with Jens' patch, but now only one instead of
two per mount.

Re: new barrier warnings in 2.6.29-rc1

[Jens Axboe]

On Sun, Jan 18 2009, Christoph Hellwig wrote:
> I still see the warnings with Jens' patch, but now only one instead of
> two per mount.

Hmm weird, I'll run and fix it locally.

-- 
Jens Axboe