Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755449AbZC3Rsw (ORCPT ); Mon, 30 Mar 2009 13:48:52 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752206AbZC3Rsj (ORCPT ); Mon, 30 Mar 2009 13:48:39 -0400 Received: from smtp1.linux-foundation.org ([140.211.169.13]:39880 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752165AbZC3Rsi (ORCPT ); Mon, 30 Mar 2009 13:48:38 -0400 Date: Mon, 30 Mar 2009 10:34:32 -0700 (PDT) From: Linus Torvalds X-X-Sender: torvalds@localhost.localdomain To: =?ISO-8859-15?Q?Fernando_Luis_V=E1zquez_Cao?= , Jens Axboe cc: 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, tj@kernel.org Subject: Re: [PATCH 1/7] block: Add block_flush_device() In-Reply-To: <49D0B687.1030407@oss.ntt.co.jp> Message-ID: References: <49C93AB0.6070300@garzik.org> <20090325093913.GJ27476@kernel.dk> <49CA86BD.6060205@garzik.org> <20090325194341.GB27476@kernel.dk> <49CA9346.6040108@garzik.org> <20090325212923.GA5620@havoc.gtf.org> <20090326032445.GA16999@havoc.gtf.org> <20090327205046.GA2036@havoc.gtf.org> <20090329082507.GA4242@infradead.org> <49D01F94.6000101@oss.ntt.co.jp> <49D02328.7060108@oss.ntt.co.jp> <49D0258A.9020306@garzik.org> <49D03377.1040909@oss.ntt.co.jp> <49D0B535.2010106@oss.ntt.co.jp> <49D0B687.1030407@oss.ntt.co.jp> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=windows-1252 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1129 Lines: 35 On Mon, 30 Mar 2009, Fernando Luis V?zquez Cao wrote: > + int ret = 0; > + > + ret = blkdev_issue_flush(bdev, NULL); > + > + return (ret == -EOPNOTSUPP) ? 0 : ret; Btw, why do we do that silly EOPNOTSUPP at all? If the device doesn't support flushing, we should - set a flag in the device saying so, and not ever try to flush again on that device (who knows how long it took for the device to say "I can't do this"? We don't want to keep on doing it) - return "done". There's nothing sane the caller can do with the error code anyway, it just has to assume that the device basically doesn't reorder writes. So wouldn't it be better to just fix blkdev_issue_flush() to not do those crazy error codes? [ The same thing probably goes for those ENXIO errors, btw. If we don't have a bd_disk or a queue, why would the caller care about it? ] Jens? Linus -- 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/