Re: EXT4-ish "fixes" in UBIFS

[David Rees <drees76@gmail.com>]

On Thu, Apr 2, 2009 at 10:02 PM, Theodore Tso <tytso@mit.edu> wrote:
> On Thu, Apr 02, 2009 at 07:58:17PM -0700, David Rees wrote:
>>
>> 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.

Yeah, that's probably a good workaround for the server in question.  I
don't recall it ever crashing.

> 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.

I think that would be a welcome addition to the writeback mode of ext3.

> People will still be better off moving to ext4, but for people who
> aren't quite confident in ext4's stability yet and who want to stick
> with ext3, maybe it's a good short-term solution.  Maybe
> data=writeback with the rename hueristic would be a better default
> than data=ordered for ext3.

I've been waiting for Fedora to ship either the latest stable 2.6.28
or 2.6.29 kernel before putting any serious data on ext4 - from what
I've seen it seems like those kernels should have the vast majority of
stability bugs fixed in them.  Last I remember reading the 2.6.27
doesn't quite have all the fixes due to difficulties in backporting
those fixes to that kernel.

-Dave