OSNews

May I ask if there is still people downloading the 6 cds or the DVD? I see no point of such desition.

The single live cd should be enought.

hiev: it's very useful for people who do not consistently have a high-speed internet connection available.

It will on final version.

The beta freeze happened a while back, before 2.26 final came out. We were in freeze for quite a while, the release was delayed to fix some critical bugs in the installer's disk code.

That's not true. The fixes were merged for the kernel ahead of 2.6.30 release and backported to the rawhide kernel a while back. The beta release has the fixes already.

Moreover Eric Sandeen, one of the primary developers of Ext4 is a Red Hat developer and Fedora has included Ext4 as a option right from Fedora 9 release. We have solid testing, feedback and fixes for several releases now.

1) no "we" don't have solid testing because all this happened
2)2.6.30 is planned for summer (?) so it is not here yet
3) no it is not the same with backporting (there are some problems)
4) read Linus comment about ext4 about at lkml after 2.6.29 release.

I will trust the Ext4 developers assertions better than a random poster. If you have actual descriptions of problems, let me know. Rawhide kernel has all the patches that is going into 2.6.30. Linus has commented on Ext3 as well. No big deal. Again, if you don't have specific bug reports on actual issues, there is nothing much to do. Ext3 continues to remain as a option if you want to pick a conservative choice.

Edited 2009-03-31 19:08 UTC

Try the thread on

http://thread.gmane.org/gmane.linux.kernel/811167/focus=811431

There are multiple sub-threads on that topic so you will have to go back and forth a bit.

Thanks. The first one I found with my google search was this doozy, in which Linus goes so far as to label Ted "incompetent":

========================
On Tue, 24 Mar 2009, Theodore Tso wrote:
>
> Try ext4, I think you'll like it. :-)
> Failing that, data=writeback for single-user machines is probably your best bet.

Isn't that the same fix? ext4 just defaults to the crappy "writeback" behavior, which is insane. Sure, it makes things _much_ smoother, since now the actual data is no longer in the critical path for any journal writes, but anybody who thinks that's a solution is just incompetent.

We might as well go back to ext2 then. If your data gets written out long after the metadata hit the disk, you are going to hit all kinds of bad issues if the machine ever goes down.

Linus
=======================

Edited 2009-03-31 19:25 UTC

no problem:
http://lkml.org/lkml/2009/3/24/460
http://lkml.org/lkml/2009/3/24/415

of course I would suggest to read all because there are different arguments and points of view.
However, one cannot call something "thoroughly tested" if patch was introduced recently.
That is a whole point.

Moreover this (data loss) was a problem with xfs, which was fixed two years ago (patched in 2007). So with all due respect for ext4 developers (including the one who came from xfs), it seems that they may somehow skip other obvious (and well described) reasons for fs malfunctioning.

I have no doubts that eventually all problems will be ironed out, but I don't think that this is it now.

From what I understood Linus was mostly complaining about the default settings for ext4 which could cause dataloss. However, you only need to specify one single option when mounting ext4 and the problem goes away.

that is not what this bug was/is about. The problem is with the order data are written.
If you apply this "single option" you can as well go back to ext3 which is better tested.

Edited 2009-03-31 19:32 UTC

"Moreover this (data loss) was a problem with xfs, which was fixed two years ago (patched in 2007). So with all due respect for ext4 developers (including the one who came from xfs), it seems that they may somehow skip other obvious (and well described) reasons for fs malfunctioning."

Err, all the patches going into 2.6.30 are based on the same hacks that went into XFS.

http://lwn.net/Articles/323752/

It looks to me like Ted is too focused on benchmark numbers to realize the inevitability of allocate-on-commit as an ext4 feature, and furthermore, as a default. Anyone who cares about Linux's reputation for stability must accept that writing metadata ahead of data is simply insane. And if that hurts us in some benchmarks, then so be it. People who don't case about their data can always revert to the unstable behavior which is the default, even with the 2.6.30 patches.

err, these patches were introduced two years ago.
so this was known, problem and fixed long time ago in xfs. Still it needed this whole hoopla now before known issue was fixed (but not tested in ext4)

Actually, wrong again. Ted did know about this problem and commented about it in the FOSDEM 2009 video and said that he was pushing in patches that followed the XFS ideas long before this problem was well known.

http://lxer.com/module/newswire/view/116126/#ext4

The actual video that has more details is available online and was pointed out by a previous poster

Yes a few distributions will include the set of patches even if they are shipping 2.6.28 or 2.6.29.

There is quite a lot info on ext 4 at:
http://thunk.org/tytso/blog/

And a FOSDEM2009 video at:
http://fosdem.unixheads.org/2009/maintracks/

Edited 2009-03-31 19:23 UTC

2)2.6.30 is planned for summer (?) so it is not here yet
3) no it is not the same with backporting (there are some problems)

No, 2.6.30 is not released yet so that's why the fixes were backported. And what is the problem with backporting a patch to an earlier kernel? I'd love to hear your explanation. The patch is essentially exactly the same, the difference is just that the backport patch compiles fine against an older kernel.

4) read Linus comment about ext4 about at lkml after 2.6.29 release.

From what I understood Linus was mostly complaining about the default settings for ext4 which could cause dataloss. However, you only need to specify one single option when mounting ext4 and the problem goes away.

Actually his blog post claims that you will get a good performance boost but there is definitely a penalty.

Personally I like that Fedora pushes the bleeding edge a bit, if I wanted guaranteed stability I'd be running Debian or CentOS. As for Ext4 specifically, it's no worse than the old days of distros including ReiserFS as the default methinks. I distinctly remember some downright nasty issues in the 2.4 series with that one.

The patches for that issue are in the Fedora kernel already.

Of course, you shouldn't trust any data you can't lose to a beta release of any software.

I'm really not an expert on the area. If you are, this is the patch that's in Fedora's kernel:

http://cvs.fedoraproject.org/viewvc/rpms/kernel/devel/linux-2.6-ext...

if you're an expert and understand exactly what the hell they're talking about, go ahead and look and see if that's the behaviour you'd like or not. If not, then use ext3 instead, I guess.

The patches keep previously existing files from ending up truncated after a crash. But new files that were created less then 60 seconds before the crash will still show up as 0 length files. Data and metadata still have a large window of time in which they are out of sync.

In contrast, with ext3, the files would either exist, or they would not. If the crash occurred at least 5 seconds after the write, they would exist and contain the expected data. If the crash occurred less than five seconds after, this might still be the case. But in the worst case, the files are not written at all. In all cases, ext3 would maintain the disk in either its state before the completed write, or its state afterwards, data and metadata remaining in sync.

You say that I should just use ext3. But that's not the point. Sacrificing Linux's reputation for reliability for the sake of better benchmark numbers is simply not a good trade.

If you can actually produce zero length files as you describe, I would be interested. I know noone who has in practise managed to do that yet and yes, I tried pulling power and crashing the system deliberately a few times while writing large amount of data.

If ext4's current default config is truly robust, that's great. I'm very excited about ext4. But I would be interested in how you would relate your observations to the quote, below, from Ted's blog. If you could satisfactorily resolve that discrepancy, then I would probably be satisfied. Even happy. :-)

=======
Another solution is a set of patches to ext4 that has been queued for 2.6.30 merge window. These three patches (with git id’s bf1b69c0, f32b730a, and 8411e347) will cause a file to have any delayed allocation blocks to be allocated immediately when a file is replaced. This gets done for files which were truncated using ftruncate() or opened via O_TRUNC when the file is closed, and when a file is renamed on top of an existing file. This solves the most annoying set of problems where an existing file gets rewritten, and thanks to the delayed allocation semantics, that existing file gets replaced with a zero-length file. However, it will not solve the problem for newly created files, of course, which would have delayed allocation semantics.
=======

The bolding, above, is mine, of course.

Edited 2009-03-31 23:07 UTC

"You say that I should just use ext3. But that's not the point. Sacrificing Linux's reputation for reliability for the sake of better benchmark numbers is simply not a good trade."

That's not a debate for this thread. Take it to LKML.

Newly created files having delayed allocation didn't actually result in zero length files in my tests nor was it the problem originated stated in bug report. My tests were simply to copy a large ISO file and pull the power within 10 seconds and run md5sum on it. It worked out fine. Of course, I might be testing the wrong thing.

I don't see the problem.

If you lose power, you lose data that hasn't been written to disk yet.

This is different how? It isn't different at all!

Ext4 may default to 60 seconds instead of 5 but that is tunable.

Windows has the same issue with NTFS when you go into the control panels and enable advanced performance. It also lets you set a checkbox for "yes I have battery backup, go more faster."

I've lost entire directories to NTFS with those settings enabled when plugging a USB device made the system freeze.

I guess what Linux users need is hmm, some way to choose what filesystem they want to run? That would be an amazing idea! Why has no one thought of it?

The theme will be changed before the general release. This was just for the beta to get more feedback going. The new design preview can be seen at

https://www.redhat.com/archives/fedora-art-list/2009-March/msg00179....

Ah, thanks Rahul. I do like that lion theme and based on that thread, it seems likely that it will be the default, which would be cool. Hopefully the GTK colors (especially the blue) will be toned down a bit to match the darker blue in that lion wallpaper.

Overall, though, it's definitely an improvement over the current.

...removed post, Rahul already addressed artwork related message.

Edited 2009-03-31 18:21 UTC