Ext3 has become one of the most popular Linux filesystems. However, with hard drives sneaking up on a terabyte, concerns exist that ext3 won’t be able to handle 21st-century storage requirements. With this in mind, the Linux kernel developers have just released the first real-world test version of ext4.
Its not bad with choice, but we already have so many filesystems that are supposed to scale well, are open source, and are free software.
We have XFS, JFS (version 1), BeFS (BFS), and the latest ReiserFS, amongst surely more.
Although it is early for ext4, it would be nice to see how the current incarnation performs against these.
Ext4 is a lot better in practical situations, upgrading from Ext3 to Ext4 is supposed to be as easy as Ext2 to Ext3. I hoped that Reiser would have some tools for conversion from v3 to v4 but there are none. Easy migration is a killer feature for a lot of people.
I can’t wait for ext4 i hear alot of good things about it but can anyone tell me if there are any speed improvements. From what I heard reiser4 is really fast but recovery sucks and ext3 is pretty good so i hope this will be a file system that builds upon this stability and reputation.
Ext3/4 codebase constantly sees performance improvements, for example,
http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=…
More information about the developments is at
http://fedoraproject.org/wiki/ext3-devel
Well reiser4 is much more resistant to problems in the first place, as its an atomic filesystem. fsck and stuff aren’t too important if the filesystem doesn’t develop the problems in the first place. Improper shutdowns shouldn’t be as much of a problem for reiser4, while ext4 will continue to have comparatively more problems with it…
This is going to murder reiserfs, especially with all the news going on lately. Seems like it has a lot of killer features. And here I thought that the ext3 branch was dead, never to be found.
Erm… quite distasteful…
Oh god, that was funny.
😀 – funny – + – I think the problem there is when people read such humour is that they think that its opinion which of course it is not & get offended .
& Yes of course POLITICAL CORRECTNESS looms over many people’s heads .
But good luck Mr Reiser assuming you are innocent or “naughty-naughty” if he commited murder – yes or no – all of which still has to be proven in a hopefully reasonably just system & way .
Hilarious actually.
People need to lighten up. Political correctness is a disease.
I wouldn’t be surprised if those who think reiser jokes as disgusting, are Americans. A country where PC is rife (Ignoring the fact you probably chuckled at it as well).
ugh, ‘PC’ is all around me here in the states. its SUFFOCATING. i hates it.
We have lots of PC in the states so that people wont want to chop our heads off. We already have people wanting to chop our heads off for Iraq and other things. Don’t want to get hemmed up at close quarters! LOL!
fo sho.
i too thought his post was hilarious. i gave it a +
too bad non members cant see it.
I know this is treading dangerous waters, but I notice that this new experimental filesystem was added to Morton’s experimental to-be-mainlined kernel while Reiser4 has spent years getting to that point. This is only the second time I’ve heard about EXT4 (on OSNews)
I suppose the difference could be related to the unusual things Reiser4 does, the state of its code, Hans Reiser’s stubborn insistence on having things his way, and the way EXT4 is more or less an extension of EXT3 (already proven and in the kernel)
But still, I find that pretty interesting.
i think you hit it mostly on the head.
this same “question” showed up on kerneltrap when EXT4 was talked about there.
mostly its about reiser4 being a very black boxed code, dumped into the kernel in big blobs. and the code often have reimplementations of things the kernel allready does at a genereal level, but remade specificaly for reiser4.
in many ways, its a clash of cultures. EXT4’s developers plays inside the existing culture of the linux kernel development. hans reiser and crew works outside of the culture and at times does things that are at odds with the linux kernel culture. result? sparks fly. some times setting of flame wars.
still, it may be the mark of a good hacker when one can stay the course even when people point out the percieved flaws in that course. problem is that this often lead one to do things ones own way, and cooperation suffers.
A. Ext4 is basically just an extension of Ext3, and is therefore a very safe addition.
B. Reiser4 does a lot of new things that filesystems haven’t traditionally done, meaning there are lots of issues to think about and bugs that could crop up. And you have the old school file system developers who say that a filesystem shouldn’t do any more than they already do trying to block it.
C. Hans Reiser really pissed off a bunch of kernel developers, and they are determined to make sure every little nitpick they can think of gets resolved before they grudgingly give him the go ahead.
D. Ext3/4 is being worked on by a lot of the same people that actually have to give the go ahead for Reiser4. They are already in important positions while Reiser is an outsider. I think Ext3 is very close to being the official Linux filesystem, even if there is no such thing in reality.
Edited 2006-10-13 06:17
I think Ext3 is very close to being the official Linux filesystem, even if there is no such thing in reality.
On every recent poll I’ve seen about linux filesystem preference, people always voted up ext3 to the top. I won’t go into detailing why I use something else, but I’d really like to know some resons behind that, aside performance issues since many filesystems are good for many things and there’s no filesystem that it’s better than all others in everything.
Is it because it’s a default choice for many distros, so people leave it that way, see that it works and than vote for it ? Is it because of some hidden hostility for other filesystems ? Or just because they don’t know and thus they don’t trust them ?
1) Every Filesystem except Reiser3/4 really sucks at many very small files. Many small files are being found at my /home partition.
2) Where Reiser3/4 sucks is processor utilisation during read and write. That is where XFS shines.
The processor is most heavily used when applications start.
Therefore all my partitions are XFS except the /home partition, that is a Reiser3 filesystem.
I don’t know how the latest kernels’ EXT3/4 filesystems perform compared to XFS and Reiser3, but a filesystem is nothing I would like to change every year on /home because it involves lots of data shuffling.
Could someone maybe name some points where EXT3/4 is/will be best?
http://linux.wordpress.com/2006/09/27/suse-102-ditching-reiserfs-as…
1) Every Filesystem except Reiser3/4 really sucks at many very small files. Many small files are being found at my /home partition.
I can give you fairly many examples for the contrary. I use ext3, reiser3 and xfs, at home, two laptops, a server, removable storage, etc. I’ve seen about all of them stumble if given directories with really large number of files. I also use XFS at home and some other places, and reiser3 on laptops generally, a choice which was a result of some years of trials.
Ext3 is “default” filesystem. I use Ext3 because it’s easily accessible by other operating systems, even Windows. It has also simple upgrade path, because newer versions are just extensions of existing fs the whole process is very easy.
I used XFS for a long time and it’s a really good filesystem but at the time it wasn’t supported in FreeBSD and it’s still unreadable in Windows AFAIK.
I used Reiser v3 and v4 too, they are certainly fast when operating on large amounts of small files. Setting up Gentoo’s portage on Reiser partition made things like updating portage tree noticably faster. But when using it on my root or home partition there were some troubles. CPU usage spiked when doing a lots of stuff (copying huge amounts of data) and with Reiser4 it became even worse.
My reason for using ext3 (and ext2 before that) is that I have found it to be rock solid.
I have never suffered any data loss in the last 10 years of using ext[23].
For me, I can live with the sacrifice of a small amount of performance in return for knowing my data isn’t going to going up in flames!
I can’t say the same for other FSs.
Edited 2006-10-13 13:50
My reasons for using ext3 are that it makes more data integrity guarantees than any other Linux fs and does it by default, has one mode that offers even more data integrity guarantees, and another mode that allows you to drop back to what most journalling filesystems guarantee. It is also the best tested and the most cleanly integrated with the rest of the kernel.
Plus, for most workloads, its performance in data=writeback mode, the one that gives the same guarantees as other journalling filesystems and is not the default, is quite comparable to other Linux jounalling filesystems. Oh, it has its performance strengths and weaknesses, like any other fs. But it is comparable.
Reiser3 has, I believe added ordered mode and full data journalling mode. But I wouldn’t let a Namesys fs touch my data.
Plus, ext2/3/4 devs are just so wonderfully pragmatic. They knew, when they made data=ordered the default mode that it put them at some disadvantage with respect to performance. But they did it anyway, because it was the *right* thing to do.
As a consequence, users data has been better protected… and ext3 has an undeserved reputation for being slow.
BTW, if anyone decides to do any bencmarking between the different modes, be advised that simply adding the data=whatever option to fstab is ineffective for the root filesystem, as once the fs is mounted, the mode can’t be changed, and a request to do so silently fails. You have to muck with the initrd to change the mode for /.
Everybody know that linux VFS is not VFS, it is just tweaked part of ext2/ext3 code that forced to use by RedHat team ($). Stop ext3 adv, please, it is SLOWEST fs ever. Namesys error was to deal with linux, not MS. Imagine – Shiny snappy Vista on Reiser4/5/6 and poor small Linux stuck with 5+ minutes boot, horrible small files performance, etc.
Not dangerous. Just surprisingly uninformed. Did you miss the stories about this? The ext devel guys were going to just add these needed features to ext3 as they have dir_index and many others. There was a big debate over their doing this on lkml (incredible, I know) with concerns flying back and forth about backwards compatibility and user confusion, etc.
It was unclear which was the best way to go. Add them to ext3? Start ext4?
Finally, it was decided to start an ext4 branch for the continued evolution of ext. New features will go there, one by one as they are developed and accepted.
And you want to compare that with reiser4, that large piece of alien code that wants to drag in its own, parallel, vfs layer that only it can use, from a company with a track record of abandoning filesystems once they get accepted into the mainline kernel and get all excited about reiser(x+1)?
Edited 2006-10-13 15:31
and the way EXT4 is more or less an extension of EXT3 (already proven and in the kernel)
Yes, I am somewhat informed. I read the story about how EXT4 is a new name for all these major additions to EXT3 (to reflect that EXT3 has changed a lot). I was just commenting on how much easier it is to get the ‘new’ EXT4 into the kernel whereas Reiser4 has been struggling due to stubbornness and bizarre code.
And I’m also informed about the weird files-as-directories thing Reiser4 has (analogous to the resource and data forks in HFS+? In which case, might they break standard POSIX utilities?), its plugin architecture that poses all sorts of compatibility problems, and the general uncooperativeness of Hans Reiser and NameSys to the point where they won’t admit to Reiser4 flaws.
I guess you can accuse me of willfully misinterpreting EXT4… No doubt the situation would be the same if Reiser4 was just Reiser3.6 with features added.
Oh, and by dangerous, I meant going off-topic and mentioning Rieser4 in an EXT3/4 article.
Reiser4 is such a promising technology:
-Transactional operations over multiple files.
-Full data journaling.
-Efficient small files.
-Plugins
This is everything microsoft wanted to do with vista but could not. But just because hans reiser does not want to use the crufted and limiting vfs layer, it does not even get a chance.
Linux will forever be doomed to play catch-up with apple and microsoft because of people like al viro that think that unix is perfect and every feature developed after 1980 is useless bloat.
“hans reiser does not want to use the crufted and limiting vfs layer”
That is exactly the point. Instead of proposing improvements to the vfs layer from which all filesysems might profit, he tried to do his stuff outside the vfs layer. This would most likely lead to future improvements which would now affect only the vfs layer to also affect the seperate ReiserFS layer. Which in turn is a maintainence nightmare. Therefore they decided against that.
Both parties have valid arguments for and against that approach, but in the end the ReiserFS guys are not responsible for the sanity of the overall kernel. Linus is, and he made his decisions.
So far Linus’ leadership prooved to be a very good one, maybe he did make a wrong decision here, maybe not. But I think the fact that he made a decision is telling enough, he saw serious issues with the original approach. Because Linus (according to his own words) trys to avoid big decisions.
re: gustl
Have you ever tried getting an extension to the VFS layer committed? It is even harder than getting a file system improved. There are all these unix purists that think that everything that has not been in unix is not necessary.
There is no way you could get something like transaction support into the VFS. All old-school unix guys would argue that something like transactions or efficient access to small files should not be in the file system in the first place. And even if you could get them to grudgingly accept the feature, they would argue that a feature can only go into the vfs when it is possible to implement it for all legacy file systems.
Good luck with implementing transactions for ext2 and fat16 🙂
Since hans reiser saw no chance at all to update the vfs, he proposed to have a new system call. But I guess that the only thing that would be acceptable for the linux kernel developers would be to castrate reiser4 and provide no interface at all to the new features.
It is a shame, but with this and the refusal to define a stable binary interface, I have pretty much given up on linux.
The kernel developers have to worry about system integrity, so of course committing duplicate functionality and functionality that doesn’t fit well into the existing design would face resistance. Kernel developers also don’t want to fill the kernel with permenent stuff that could just as easily (and more securely) be placed in user space.
Both of these reasons are why IBM’s featureful but complex LVM didn’t get into the kernel and instead a less featureful but well integrated LVM went in its place. However, IBM worked with the kernel community so that the less featureful LVM could be extended and combined with userspace tools to give all of IBM’s LVM features. That’s the way it supposed to work and should have worked with Reiser.
The part about “all features in the VFS have to work with all file systems” is clearly not true. For instance, VFAT doesn’t support symbolic links or half the characters that POSIX file systems do, and yet are included in the kernel. I don’t think anyone expects VFAT to ever get transaction support (although it may be possible with some hack).
You’re completely misunderstanding the concerns of the kernel developers. They see that most *modern* file systems will want to have transactions, so since that’s the case, there should be a common API that all could use. This is just part of the kernel developer’s desire to have a maintainable kernel and has nothing to do with Reiser. They’ve used the “common API” restriction for other kernel subsystems such as Xen/VMWare, the common resource virtualization spec, the VFS (obviously), and various other parts of the system. It’s a good thing and allows common userspace tools to be file system independent without much concern.
The vfs is just completely useless for what reiser4 wants to do. The core idea of reiser4 is that applications should not have to write their own pseudo file systems to store many small data items. Instead they should just use the file system. It fits very well with the unix philosophy that “everything is a file”.
But for small files, the traditional unix approach is completely useless. The overhead of file handles and the vfs might be acceptable for a file that is several megabytes large. But if you want to open many thousand files with a size of a few bytes, the overhead is tremendous.
So as long as you have to go through the vfs and use the traditional unix approach with file handles and all that, there is simply no way reiser4 can meet its design goals.
I think it was a mistake by hans reiser to try to do something really novel in the linux kernel. The linux kernel is not the right place to innovate.
Now that hans reiser is in jail, reiser4 will probably slowly die. And I will be using transactional ntfs under windows vista. It is a toy compared to reiser4 and zfs, but sadly miles ahead of anything that linux has to offer.
With the little I understand about filesystems & how it’s done in Linux your explanation of overhead makes sense to me .
To me it sounds like packaging eggs each in its little box instead of throwing many into a single box which when moving is packaging-wise more efficient etc.
Reg VFS devs – kernel devs if not otherwise “publicly” known to be problematic have a thick coat of “Angel shine” magically applied to them
Saying that devs will not possibly react emotional or stubborn etc but will always be deciding objectivly on technical terms seems rather naive to me .
They are humans as well therefore their decisions are also influenced by emotions .
😀 – They are not vulcan – logic will not always be the primary decision factor .
Hmm – the kernel should be the place to innovate – pity if non-technical or rescource issues hold things back IMO .
Hans Reiser is not in prison/jail AFAIK .
The investigations yet have to come to conclusions .
Isnt there an effort to port ZFS to Linux ?
Why not if not ?
EDIT : I remember reading about these kind of VFS issues in the Linux 2006 Symposium paper ( vol.1 starting page 87 ) regarding the K42 filesystem :
http://domino.research.ibm.com/comm/research_projects.nsf/pages/k42…
Edited 2006-10-13 21:43
Apparently there are at least two projects in the works, though they seem very prelinary.
http://www.sun.com/emrkt/campaign_docs/expertexchange/knowledge/sol…
http://zfs-on-fuse.blogspot.com/
> That is exactly the point. Instead of proposing
> improvements to the vfs layer from which all filesysems
> might profit […]
It sounds much more as if an improvement to the VFS layer would be near impossible because it would expect a lot of features from *every* file system which only ReiserFS could implement. With the traditional Unix way of thinking (about what files and file systems are), ReiserFS is *not* a file system. To make it work with the VFS layer, one would have to redefine what files / file systems are, which would in turn cause problems with all other file systems. Or worse, prefer quick and dirty hacks over a clear definition and VFS structure.
(I say this without knowledge of the actual problems in the case of ReiserFS, just with knowledge about this kind of problems in general and how they are generally handled).
Reiser4 is such a promising technology:
-Transactional operations over multiple files.
-Full data journaling.
-Efficient small files.
-Plugins
Indeed. But even Microsoft had to play with backwards compatiblity when they had to allow FAT32 partitions to be converted to NTFS. You can’t do that with Reiser 3 to Reiser 4, which makes it very difficult to use in practice and doesn’t inspire confidence. You can convert ext filesystems.
Linux will forever be doomed to play catch-up with apple and microsoft because of people like al viro that think that unix is perfect and every feature developed after 1980 is useless bloat.
Just because he is damn good at findind issues and he points out them and requires people to fix them, doesn’t means he’s opposed to “new things”
For example, he has publicy said that he’s OK with the innovative “files-as-directories” idea that hans reiser and linus seem to like. But he was not OK with the racy reiser4 implementation of the feature. I guess he also didn’t like that hans tried to sneak in reiser4 despite of the fact that it’s obvious hans knew reiser4 was not ready
Yes, reiser4 groupies (including hans) loved to talk of him like an anti-innovative guy, but in the real world I haven’t seen him oppose as long as it has a good design and it’s not broken. You can’t blame him for having good taste and being extremely “energic” when pointing out issues of broken code, like the reiser4 code when it was reviewed.
BTW, he’s also the guy that implemented in the first days of 2.5 the first steps to implement per-process filesystem namespaces, a very innovative feature invented by the Plan 9 people. Plan9, the operative system that was born to fix Unix. Yeah, he really sounds like the kind of antinnovative guy that thinks that “unix is perfect”
Edited 2006-10-13 13:48
Well, I’m not sure I would trust Hans Reiser accused of murdering his wife, to develop the file system for Linux!
As I recall, a petabyte is 2^15, not 2^50
“In computer science peta- can sometimes mean 1 125 899 906 842 624 (10245 or 250), instead of 1 000 000 000 000 000, especially when used to prefix the byte, giving a petabyte. To resolve this ambiguity, the term pebibyte has been suggested to mean 250 bytes. However, this term is not yet widely used.”
From http://en.wikipedia.org/wiki/Peta_%28prefix%29
You probably confused it with 10^15 which is indeed called peta.
2^50=1.13*10^15~=10^15
Same as with kb=2^10=1024b
does it have versioning ???
In threads about filesystems, one often hears certain “truths” stated. Things that “everybody knows”:
* Reiserfs is great for directories with lots of small files.
* XFS is FAST!
* XFS is great for streaming large files sequentially.
* Ext3 is slow.
That sort of thing.
As it happens, I just finished running bonnie++ on Ext3, reiser3, XFS, and JFS. I found the data collected to be interesting, though not altogether surprising, since I’ve always been skeptical of these claims.
The machine configuration:
Celeron 2GHz
512MB ram
LaCie 250GB USB 2.0 Drive
Fedora Core 5 (Fully updated)
kernel 2.6.17
All tests were run on the same partition of the same drive after a fresh mkfs. (Even in the cases in which I tested the same fs with different mount options, I ran mkfs each time.)
Note how ext3 (dir_index enabled) in writeback mode not only beats reiser3, but actually *humiliates* it in the case of working with lots of little files in a directory… *with* or *without* the notail option. (200,000 files were used in the test.)
Reiser’s B+ Trees are no match for ext3’s directory indexes.
Note reiser3’s processor hungry nature. (No surprise there.)
Note how XFS, which is supposed to be so much faster and better at streaming large files, doesn’t really distinguish itself.
Note how ext3 in writeback mode is, overall, the fastest filesystem of the bunch.
I should say that without dir_index, ext3 performs about like the rest in the case of many small files. But it’s not like ext3 has not had that feature for 4 years now.
The labels are thus:
ext3wb: ext3 with data=writeback
ext3ord: ext3 with data=ordered
ext3jrn: ext3 with data=journal
reiser3: reiser3
reiser3-nt: reiser3 with notail
xfs: XFS
jfs: JFS
(I hope this formats OK.)
Version 1.03 ——Sequential Output—— –Sequential Input- –Random-
-Per Chr- –Block– -Rewrite- -Per Chr- –Block– –Seeks–
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
ext3wb 1G 33847 17 14046 9 25699 12 238.5 1
——Sequential Create—— ——–Random Create——–
-Create– –Read— -Delete– -Create– –Read— -Delete–
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
200 14843 90 173793 100 22314 76 14053 85 269013 100 17512 61
Version 1.03 ——Sequential Output—— –Sequential Input- –Random-
-Per Chr- –Block– -Rewrite- -Per Chr- –Block– –Seeks–
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
ext3ord 1G 32459 20 13932 14 25477 7 245.1 1
——Sequential Create—— ——–Random Create——–
-Create– –Read— -Delete– -Create– –Read— -Delete–
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
200 14721 88 173155 100 21742 74 14200 84 273382 100 19678 69
Version 1.03 ——Sequential Output—— –Sequential Input- –Random-
-Per Chr- –Block– -Rewrite- -Per Chr- –Block– –Seeks–
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
ext3jrn 1G 12783 10 9279 16 29215 9 251.5 1
——Sequential Create—— ——–Random Create——–
-Create– –Read— -Delete– -Create– –Read— -Delete–
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
200 14631 89 174801 100 21060 73 14126 85 275605 100 19430 69
Version 1.03 ——Sequential Output—— –Sequential Input- –Random-
-Per Chr- –Block– -Rewrite- -Per Chr- –Block– –Seeks–
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
reiser3 1G 34233 25 14125 12 25662 26 240.6 1
——Sequential Create—— ——–Random Create——–
-Create– –Read— -Delete– -Create– –Read— -Delete–
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
200 2314 28 237029 100 2380 27 2045 25 270321 99 904 12
Version 1.03 ——Sequential Output—— –Sequential Input- –Random-
-Per Chr- –Block– -Rewrite- -Per Chr- –Block– –Seeks–
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
reiser3-nt 1G 33908 26 14139 12 25650 26 242.4 1
——Sequential Create—— ——–Random Create——–
-Create– –Read— -Delete– -Create– –Read— -Delete–
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
200 2332 29 167613 74 2373 27 2024 26 269895 100 897 13
Version 1.03 ——Sequential Output—— –Sequential Input- –Random-
-Per Chr- –Block– -Rewrite- -Per Chr- –Block– –Seeks–
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
xfs 1G 29305 13 15352 21 26535 16 207.5 1
——Sequential Create—— ——–Random Create——–
-Create– –Read— -Delete– -Create– –Read— -Delete–
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
200 1750 62 222923 99 1610 32 1571 56 91454 86 756 14
Version 1.03 ——Sequential Output—— –Sequential Input- –Random-
-Per Chr- –Block– -Rewrite- -Per Chr- –Block– –Seeks–
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
jfs 1G 33383 10 14197 8 26176 9 250.0 1
——Sequential Create—— ——–Random Create——–
-Create– –Read— -Delete– -Create– –Read— -Delete–
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
200 6690 70 214138 84 2347 16 1919 41 2698 6 404 5
Edited 2006-10-14 00:50