[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110523173350.GA10554@infradead.org>
Date: Mon, 23 May 2011 13:33:50 -0400
From: Christoph Hellwig <hch@...radead.org>
To: Jan Kara <jack@...e.cz>
Cc: Alex Bligh <alex@...x.org.uk>, linux-kernel@...r.kernel.org,
Christoph Hellwig <hch@...radead.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Andreas Dilger <adilger.kernel@...ger.ca>,
Theodore Ts'o <tytso@....edu>
Subject: Re: BUG: Failure to send REQ_FLUSH on unmount on ext3, ext4, and FS
in general
On Mon, May 23, 2011 at 07:29:06PM +0200, Jan Kara wrote:
> Yes, but that's rather a deficiency in default mount options of ext3
> which is kept for backward buggy-for-performance compatibility. Anywone who
> seriously cares about the data should use barrier=1 and BTW SUSE or RH
> distros change the default to be barrier=1. Anyway, this is a seperate
> issue.
It really should be changed. The previous (bad) excuse was that the
ordering barrier code was too much overhead. Making a filesystem
non-safe by default is already a bad sin, but having the code to make
it safe around and not enabling it is plain criminal.
> > Would there be any interested in these patches if I cooked them up,
> > or did they die because of opposition before rather than apathy?
> I guess you might come with some proposal and post it to linux-fsdevel
> (include Al Viro and Christoph Hellwig in CC) and see what happens...
There's no way to make it generic. Fortunately adding support to a
filesystem is generally trivial, take a look at my recently added
cache flushing support for hfsplus for example.
--
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