Real-World Benchmarks of Ext4 249
Ashmash writes "Phoronix has put out a fresh series of benchmarks that show the real world performance of the Ext4 file-system. They ran 19 tests on Fedora 10 with changing out their primary partition to test Ext3, Ext4, Xfs, and ReiserFS. The Linux 2.6.27 kernel was used with the latest file-system support. In the disk benchmarks like Bonnie++ Ext4 was a clear winner but with the real world tests the results were much tighter and Xfs also possessed many wins. They conclude though that Ext4 is a nice upgrade over Ext3 due to the new features and just not improved performance in a few areas, but its lifespan may be short with btrfs coming soon."
Re:butterfs (Score:5, Informative)
Re:One filesystem to rule them all... (Score:5, Informative)
Windows hasn't had a new filesystem that recently! NTFS was introduced in 1993 [wikipedia.org]. Windows has been using it for the past 15 years (if you only count the NT line, the 9x/ME line never even supported it IIRC, they just used the even older FAT32).
Of course if you want to count the small extensions [wikipedia.org] added on with each windows version then your claim about Windows is correct. Still I wouldn't be surprised if Windows Vista filesystems mount inside NT 3.1. I should test this with a VM...
Re:One filesystem to rule them all... (Score:5, Informative)
Re:Short lifespan? I don't think so. (Score:3, Informative)
What I don't understand is why more people are not using JFS?
It has good performance, it is stable, and it supports very large file systems.
Seems like a good choice for many people.
Stupid testing methodology (Score:5, Informative)
Re:butterfs (Score:4, Informative)
I like the fact that they are naming filesystems after characters in South Park. It's old-school programing, where you don't care what the end user thinks.
Re:short lifespan? The big distros will decide. (Score:3, Informative)
No need to wonder, Fedora 9 had it already back in may: http://fedoraproject.org/wiki/Releases/9/FeatureList [fedoraproject.org]
Phoronix is worthless (Score:5, Informative)
Remember, this is the site that's decided that Ubuntu 7.04 is twice as fast as any other version of Ubuntu [phoronix.com]. Take what they say with a good healthy dose of skepticism.
Re:One filesystem to rule them all... (Score:4, Informative)
Junction points have been around since at least Win2K, possibly NT4. I know I used them on 2K personally, can't speak to NT4 though. And Volume Shadow Copy requires application cooperation [microsoft.com], so it's not really that much of an improvement over standard mirroring unless you use copy-on-write, which is still not filesystem level. You need to have the apps aware of it.
Re:ext2? (Score:5, Informative)
You joke but fat with big clusters is pretty efficient for media applications. It's easy to get a good cache hit rate on the FAT cache.
E.g consider a FAT32 filesystem reading from a contiguous file. You have 512 bytes sectors 32K clusters. You have a one sector buffer for FAT data in the filesystem and a cluster sized buffer to read ahead data in the application. Each read of the FAT tells you where 128 clusters are. So you read a sector of FAT and then you can read 128 data clusters (4MB) before you need to do any metadata access. That's a very low overhead. There are no inodes to be updated, no atime and no bitmap, just the FAT, data clusters and directory entries. You need to update the time in the directory entry only once when you close the file if it has been written.
A small amount of code can get read speeds that are close to the raw read speed of the device for a contiguous file because you spend a small amount of time on bookkeeping.
Of course directories aren't indexed but lots of applications don't have vast numbers of files in a directory. In any case reading ahead as far as possible and doing a linear search is probably quicker than doing a B tree access which involves moving the hard disk head around. Even fragmentation doesn't introduce much overhead, you'd just have to reload you FAT buffer from a different place in the FAT each time you cross into a new fragment. Traditionally inode based fiesystems are worse because you have multiple levels of indirection to find the data blocks. Ext4 uses extents instead but a FAT implentation could keep track of extents in Ram so reading a big contiguous file would require FAT reads only until the filesystem works out that the file is one big extent.
If you have large directories it slows down a bit but you can always cache the mapping from files to clusters.
Most people running inode based filesystems with atime updates on, the default, probably have a filesytem which is less efficient than FAT. On Windows for example NTFS is slower than FAT in the default config with atime updates on. Kind of embarassing given that NTFS is much more high tech filesystem with Btrees fo directories and extent lists in the inodes to track data blocks.
Of course NTFS has a logfile but that only protects metadata. FAT has bit in the first FAT entry to mark the volume dirty, the idea is that you set it before you write and clear it when you're done. If you mount a filesystem with the bit set you need to do a chkdsk. Chkdsking means reading all the directories and making sure that the allocations match the FAT. It's slower than a logfile based chkdsk but it will fix corrupt metadata, mostly by freeing lost clusters. You wouldn't want to boot your OS from it, but it's good for play MP3s or AVIs from. It's also incredibly widely supported - pretty much any PC OS, games console or media player will handle it. And it works for drives of up to 2TB. Really the only problem is 4GB max file size.
Re:ZFS for the win (Score:3, Informative)
Lose two hard drives, your RAID is still AOK
That's an awfully simplistic statement, and only applicable for RAID-Z2. A simple mirror or RAID-Z can (understandably) only sustain a single failure.
Re:XFS (Score:4, Informative)
Perhaps a new filesystem can be designed from the ground up optimized for SSD.
JFFS2 [wikipedia.org]
UBIFS [wikipedia.org]
YAFFS [wikipedia.org]
Re:Stupid testing methodology (Score:3, Informative)
What about office apps? Design tools (like engineering design software)? Compilers, linkers, and interpreters? Package management (since this is linux)? File searches with the "find" command? Recursive directory copies?
The benchmark suite chosen is not representative of the "real world" usage. In the real world there are a variety apps that work on a variety of data. Not just cpu bound applications.
Re:butterfs (Score:5, Informative)
I like the fact that they are naming filesystems after characters in South Park.
I like the fact that they're naming filesystems after common household items that have existed for millenia. In South Park, "Butters" is plural.
Re:ext2? (Score:3, Informative)
Can't you tell by reading it that it's a fork bomb? I mean, any idiot should be able to figure that out! :-P
global _start
_start:
mov eax, 2 ; sys_fork
int 80h ; execute call
jmp _start ; unconditional jump to _start
Get it???
(Disclaimer: I didn't really expect you to know what it did just by looking at it. I didn't. I had to look up the system call on Google. Just don't go executing code if you don't know what it does.)