Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755241AbZDAAsU (ORCPT ); Tue, 31 Mar 2009 20:48:20 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751416AbZDAAsH (ORCPT ); Tue, 31 Mar 2009 20:48:07 -0400 Received: from hera.kernel.org ([140.211.167.34]:55137 "EHLO hera.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751388AbZDAAsF (ORCPT ); Tue, 31 Mar 2009 20:48:05 -0400 Message-ID: <49D2B8B5.9040602@kernel.org> Date: Wed, 01 Apr 2009 09:43:33 +0900 From: Tejun Heo User-Agent: Thunderbird 2.0.0.19 (X11/20081227) MIME-Version: 1.0 To: Jens Axboe CC: Linus Torvalds , Ric Wheeler , =?ISO-8859-1?Q?Fernando_Luis_V=E1zquez_Cao?= , Jeff Garzik , Christoph Hellwig , Theodore Tso , Ingo Molnar , Alan Cox , Arjan van de Ven , Andrew Morton , Peter Zijlstra , Nick Piggin , David Rees , Jesper Krogh , Linux Kernel Mailing List , chris.mason@oracle.com, david@fromorbit.com Subject: Re: [PATCH 1/7] block: Add block_flush_device() References: <20090330201732.GB5178@kernel.dk> <49D17CA2.5060105@redhat.com> <49D1FB64.8000505@redhat.com> <49D239A0.5080405@redhat.com> <20090331164312.GP5178@kernel.dk> <20090331170319.GT5178@kernel.dk> In-Reply-To: <20090331170319.GT5178@kernel.dk> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (hera.kernel.org [127.0.0.1]); Wed, 01 Apr 2009 00:43:38 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1420 Lines: 32 Jens Axboe wrote: > On Tue, Mar 31 2009, Jens Axboe wrote: >> On Tue, Mar 31 2009, Linus Torvalds wrote: >>> >>> On Tue, 31 Mar 2009, Ric Wheeler wrote: >>>> The question is really what we do when you have a storage device in your box >>>> with a volatile write cache that does support flush or fua or similar. >>> Ok. Then you are talking about a different case - not EOPNOTSUPP. >> So here's a test patch that attempts to just ignore such a failure to >> flush the caches. It will still flag the bio as BIO_EOPNOTSUPP, but >> that's merely maintaining the information in case the caller does want >> to see if that barrier failed or not. It may not actually be useful, in >> which case we can just kill that flag. > > Updated version, the previous missed most of the buffer_eopnotsupp() > checking. So this one also gets rid of the file system retry logic. > Thanks to gfs2 Steve for pointing out that I missed gfs2, made me > realize that I missed a lot more as well. Wouldn't it be cleaner to simply finish with success status from blk_do_ordered()? That is the single place that all flush/barrier ops go through and semantically better place too. Thanks. -- tejun -- 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/