Re: EXT4-ish "fixes" in UBIFS

From: Pavel Machek <pavel@ucw.cz>
To: Theodore Tso <tytso@mit.edu>, David Rees <drees76@gmail.com>,
	"Trenton D. Adams" <trenton.d.adams@gmail.com>,
	Christian Kujau <lists@nerdbynature.de>,
	Artem Bityutskiy <Artem.Bityutskiy@nokia.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: EXT4-ish "fixes" in UBIFS
Date: Thu, 9 Apr 2009 22:17:22 +0200	[thread overview]
Message-ID: <20090409201722.GA1450@ucw.cz> (raw)
In-Reply-To: <20090403050246.GM9870@mit.edu>

Hi!

> > I've got a problematic server with 8GB RAM.  Even if set both to 1,
> > that's 80MB and the crappy disks I have in it will often only write
> > 10-20MB/s or less due to the seekiness of the workload.  That means
> > delays of 5-10 seconds worst case which isn't fun.
> > 
> 
> Well, one solution is data=writeback.  If you're confident your server
> isn't going to randomly crash (i.e., it's on a UPS, and you're not
> running unstable video drivers), that might be a solution.  It has
> tradeoffs, though.
> 
> One thing which I'll probably implement is some patches to ext3 so
> that when it's in data=writeback mode, it will use the same
> replace-via-rename and replace-via-truncate hueristics that I added in
> ext4 so that it will start an aysnchronous writeout on the rename() or
> close() w/ truncate().  That should avoid existing files getting
> corrupted when they are replaced right before the system crashes.  

Truncate case is unfixable, but would it be possible to only do rename
after data are on disk? Because async writeout only makes catastrophic
data loss 'less probable'...
								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html