Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758201AbZCXOHZ (ORCPT ); Tue, 24 Mar 2009 10:07:25 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1758042AbZCXOC6 (ORCPT ); Tue, 24 Mar 2009 10:02:58 -0400 Received: from mx1.redhat.com ([66.187.233.31]:40410 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757856AbZCXOCx (ORCPT ); Tue, 24 Mar 2009 10:02:53 -0400 Date: Tue, 24 Mar 2009 10:02:43 -0400 (EDT) From: Mikulas Patocka X-X-Sender: mpatocka@hs20-bc2-1.build.redhat.com To: device-mapper development cc: Linux Kernel Mailing List , Andi Kleen , "MASON, CHRISTOPHER" , Jens Axboe Subject: Re: [dm-devel] Barriers still not passing on simple dm devices... In-Reply-To: <49C7DD3C.2020401@redhat.com> Message-ID: References: <49C7DD3C.2020401@redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3245 Lines: 104 On Mon, 23 Mar 2009, Eric Sandeen wrote: > I've noticed that on 2.6.29-rcX, with Andi's patch > (ab4c1424882be9cd70b89abf2b484add355712fa, dm: support barriers on > simple devices) barriers are still getting rejected on these simple devices. > > The problem is in __generic_make_request(): > > if (bio_barrier(bio) && bio_has_data(bio) && > (q->next_ordered == QUEUE_ORDERED_NONE)) { > err = -EOPNOTSUPP; > goto end_io; > } > > and dm isn't flagging its queue as supporting ordered writes, so it's > rejected here. > > Doing something like this: > > + if (t->barriers_supported) > + blk_queue_ordered(q, QUEUE_ORDERED_DRAIN, NULL); > > somewhere in dm (I stuck it in dm_table_set_restrictions() - almost > certainly the wrong thing to do) did get my dm-linear device to mount > with xfs, w/o xfs complaining that its mount-time barrier tests failed. > > So what's the right way around this? What should dm (or md for that > matter) advertise on their queues about ordered-ness? Should there be > some sort of "QUEUE_ORDERED_PASSTHROUGH" or something to say "this level > doesn't care, ask the next level" or somesuch? Or should it inherit the > flag from the next level down? Ideas? > > Thanks, > -Eric > > -- > dm-devel mailing list > dm-devel@redhat.com > https://www.redhat.com/mailman/listinfo/dm-devel Hi This is misdesign in generic bio layer and it should be fixed there. I think it is blocking barrier support in md-raid1 too. Jens, pls apply the attached patch. Mikulas ---- Move test for not-supported barriers to __make_request. This test prevents barriers from being dispatched to device mapper and md. This test is sensible only for drivers that use requests (such as disk drivers), not for drivers that use bios. It is better to fix it in generic code than to make workaround for it in device mapper and md. Signed-off-by: Mikulas Patocka --- block/blk-core.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) Index: linux-2.6.29-rc6-devel/block/blk-core.c =================================================================== --- linux-2.6.29-rc6-devel.orig/block/blk-core.c 2009-02-23 18:43:37.000000000 +0100 +++ linux-2.6.29-rc6-devel/block/blk-core.c 2009-02-23 18:44:27.000000000 +0100 @@ -1145,6 +1145,12 @@ static int __make_request(struct request const int unplug = bio_unplug(bio); int rw_flags; + if (bio_barrier(bio) && bio_has_data(bio) && + (q->next_ordered == QUEUE_ORDERED_NONE)) { + bio_endio(bio, -EOPNOTSUPP); + return 0; + } + nr_sectors = bio_sectors(bio); /* @@ -1450,11 +1456,6 @@ static inline void __generic_make_reques 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); > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/