Submitted by The Fedora team has announced the Fedora 11 beta release. It comes packed with new features, such as Ext4 as the default filesystem, Nouveau driver by default, kernel mode setting on Intel, ATI and Nvidia drivers, many virtualization improvements, IBus input method, GCC 4.4, and much more.
Fedora 11 comes with a load of upstream improvements, thanks to the inclusion of the latest GNOME (2.26) and KDE (4.2.1) releases. It also has experimental support for the Btrfs file system, which may become the default file system for most Linux distributions in the future. Note, though, that Btrfs is really, really volatile at this point. For more information on new features, please read the release notes.
Fedora 11 is scheduled for release on May 26. You can download the beta using Bittorrent (preferred), or you can use the mirror list.
Im trying Ubuntu jaunty beta and it is a really polished work (The new notification system rocks my world), now is time to try Fedora and compare.
Edited 2009-03-31 17:38 UTC
More information at
http://www.h-online.com/open/Fedora-11-beta-released–/news/112973
http://www.desktoplinux.com/news/NS8148594076.html
Screenshots at
http://news.softpedia.com/news/Fedora-11-Beta-Screenshot-Tour-10826…
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.
Depends what you want to do. If you want to perform a default install then yes, the live CD would be enough. But the problem with most live CDs is that they do not let you perform a custom install. The DVD allows you to customize the install. I always perform custom installs because I am a performance freak. But the DVD is a bit too much. A minimal CD or a netinstall CD are the best options.
I am very grateful to Fedora because it is truly the trailblazer distro. Fedora is one of the best things that ever happened to Linux.
GNOME 2.26 final has not been fully integrated yet?
See:
http://news.softpedia.com/newsImage/Fedora-11-Beta-Screenshot-Tour-…
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.
Ext4 as default is not a good idea. Any loss of power can corrupt your file system to the point of not being able to recover. Unless you run a battery backup consider your choices.
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
I’ve been waiting for that. Could you post a link. I’ll be googling for it. But in the twisty, tangly web of lkml posts, one never knows if he’s seen all the relevant ones.
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.
Yer, it’s a big problem. What good is metadata if the actual data it is referencing isn’t there? All you’ve got is a broken filesystem when you bring things back up. I can’t believe that.
It’s strange that we’ve had all this ‘data loss’ stuff levelled at XFS over the years as an advantage of ext3 when they’re making even more mistakes with ext4 and replicating problems and scenarios XFS has fixed.
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
so what?
until whole story poped up Nothing happened. “Pushing it?”
what does actually mean? Clean hands? Doubt it.
As long as this was not fixed, this is/was not fixed. Nobody ever mentioned this officially before ext4 problems caused so much trouble.
“Pushing it” means nothing.
Pushing it means, the side effects of delayed allocation were known as I pointed out already and patches were already written and queued for Linus to merge them, a while before these issues were raised by other people. Fedora kernel even had those backported fixes at that point.
When the merge window was 2.6.30 opened up, those patches got merged in. That’s how Linux kernel development process works. There is a merge window followed by a few weeks of stabilization and the cycle repeats itself again.
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.
But which Ted claims destroys most of ext4’s performance benefits.
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.
But those patches still leave a very significant reliability regression for ext4 vs ext3. Ted is simply going to have to accept reality, bite the bullet, and part with the benchmark numbers he seems so focused upon… for the good of everyone.
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^aEURTMs 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.
Actually, it’s your comment that is in the wrong thread.
in this thread you are talking to a community guy (me) and another community guy who does a lot of packaging and hacking but precisely no kernel hacking (rahul). You are talking to exactly 0 kernel developers. Which is why I say this is the wrong place to discuss it, because you’re not going to get anything actually done.
Hey. I’ve participated in the comments under Ted’s blog, too. But what I’m hearing from Fedora’s new PR guy (that’s you, isn’t it?) is the usual “sweep it under the rug” that I often see when anyone criticizes Fedora’s judgment. If Linux’s soon-to-be standard FS, which Fedora is making the default in the next release, is a data sieve, then it’s fair to comment on whether kernel devs are present or not.
Adam is not a PR guy for Fedora. He is part of the QA team. Again, if anyone can actually do some actual testing and come up with real problems, I would be very interested in hearing it.
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.
Well, if it can really do that, while maintaining the bulk of the speed increases, and fragmentation avoidance advantages, of delayed allocation, then I am delighted. But if that is the case, why does Ted imply that it would not be?
To my knowledge, you are not “testing the wrong thing”. That is exactly where I would expect to observe the problem.
Edited 2009-03-31 23:20 UTC
My understanding is that Ted is talking about a slightly different case where a large number of new files are being created simultaneously as in say a desktop environment creating its new settings on a new user and NOT closing the files while I am actually testing a single large write and since the write is not starved for resources (aka multiple files trying to get disk access), it will be committed as soon as close is called (even without fsync) since the Rawhide already has that patch.
http://cvs.fedoraproject.org/viewvc/rpms/kernel/devel/linux-2.6-ext…
At this point, this debate is rather silly since it seems most people participating in it haven’t actually tested it yet and I rather hear from people actually testing this thing and providing feedback on actual problems.
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?
It’s an option if you install Debian. (I can’t tell if you’re being serious).
Thanks for parroting this already stale news yet again! I’ve been running the EXT4 file system on my Debian box for months without any issues whatsoever and I highly recommend it. Of course I’ll also welcome any patches that might minimize the odds of data loss. Speaking of odds, I think they’re in my favor even with the file system as is. I’m not going to shy away from an advanced file system and its myriad features because the power just might go out on me. Do you constantly look up at the sky because you might get struck by lightning?
Personally, I don’t think ext4 is quite ready yet and I really don’t think Fedora should use that as the default file system.
I really liked Fedora 10’s theme but this theme seems pretty boring. I was hoping they were going to go with the ‘nautical’ reference to Leonidas (the HMS Leonidas). The wallpaper in those screenshots is very, very generic-looking. Granted, themes and wallpapers can be changed but Fedora has done such a great job in the past of creating a unique and cool look that this one, so far, is a letdown.
Still, Fedora is pretty darn awesome and I look forward to checking out the beta.
Edited 2009-03-31 18:01 UTC
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
Anyone else having trouble getting the GNOME Live CD to boot up in VMware Fusion? I start it up and I just get a blank Window.