[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090331060412.GG5178@kernel.dk>
Date: Tue, 31 Mar 2009 08:04:13 +0200
From: Jens Axboe <jens.axboe@...cle.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Ric Wheeler <rwheeler@...hat.com>,
Fernando Luis Vázquez Cao
<fernando@....ntt.co.jp>, Jeff Garzik <jeff@...zik.org>,
Christoph Hellwig <hch@...radead.org>,
Theodore Tso <tytso@....edu>, Ingo Molnar <mingo@...e.hu>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
Arjan van de Ven <arjan@...radead.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Nick Piggin <npiggin@...e.de>, David Rees <drees76@...il.com>,
Jesper Krogh <jesper@...gh.cc>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
chris.mason@...cle.com, david@...morbit.com, tj@...nel.org
Subject: Re: [PATCH 1/7] block: Add block_flush_device()
On Mon, Mar 30 2009, Linus Torvalds wrote:
>
>
> On Mon, 30 Mar 2009, Ric Wheeler wrote:
> >
> > One thing the caller could do is to disable the write cache on the device.
>
> First off, that's not the callers job. If the sysadmin enabled it, some
> random filesystem shouldn't disable it.
Completely agree with that, that is why I want the error logged instead
of returned. The write cache MAY be involved, but it may also be
something entirely different. The cache may be perfectly fine and
ordered but just not supporting flush cache because it doesn't need to
(it has battery backing). The important bit is informing the admin of
the situation, then it's up to the admin to look into the storage stack
and determine if this is a real problem or not. There's nothing the
kernel can do about it.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists