Filesystems benchmarked: EXT3 vs EXT4 vs XFS vs BTRFS

I wondered across this fine artical this morning, and thought I would share it with the community.
Quote:
Let's start from the most obvious: the best balanced filesystem seems to be the mature, almost aging EXT3. This is natural, as it received most cumulative improvements over a long period of time. It has very good sequential and random write speeds and reasonable read speed, factors that are of utmost importance on several different tasks. For example, if you plan to run a database server you are almost forced to use EXT3, as all other filesystems seems to have big problems with synchronized random write speed. Also, you can't go wrong with EXT3 if you use it on your workstation as its performances are quite good in a great amount of different jobs. Finally, EXT3 is more stable than the others FS as most of its bug are by now already worked out.
However, this not means that EXT3 is the perfect FS: first, it that lacks some important features as delayed allocation and online compression. It lacks native snapshots capability also but you can use LVM to overcome this. It is more fragmentation-prone that EXT4 and XFS and it is very slow in creating/deleting large amount of files, denoting a not-so-good metadata handling. Moreover, it use more CPU cycles than EXT4 and XFS, but with todays CPU I don't think that this is a great problem. If you can live with these minor faults, EXT3 is the right filesystem for you.
Please don't just read that one paragraph though, they have ten pages worth of detailed and varied benchmarks they used to form that opinion. And the artical is dated from the middle of last month, nice and recent
Interesting stuff, I thought that ext4 would do better (not that it did poorly, but relative to ext3) And that btrfs wouldnt be as slow as it currently seems, though as the tester commented, it's a very new filesystem. Maybe Arch should ship btrfs as an install option? Help these guys iron out the bugs!

fukawi2 wrote:
Misfit138 wrote: Dodge RAM 2500 Cummins Turbodiesel FTW.
F650 FTW
Well if you go there, then I have to pull out my Chevy Kodiak Pickup.
Last edited by Misfit138 (2010-12-04 02:13:59)

Similar Messages

ERP6.0 EHP7 : ext3 or ext4 filesystem

Hi Gurus,
Is using ext4(filesystem type) allowed for ERP6.0 EHP7 (RHEL6.5) ?
1839658 - Is ext3 file system supported for ECC 6.0 EHP6 on RHEL 6 or ext4 required?
SAP note above saying nothing about ext4.
Regards,
AM.

Unfortunately I don't see one but according to the SAP note 1839658 - Is ext3 file system supported for ECC 6.0 EHP6 on RHEL 6 or ext4 required? I believe EXT3 and EXT4 are supported. Maybe you can raise an OSS message and get this clarified.
Regards
RB

Ext3 or ext4

Hello,
When installing Archlinux on a new computer, which do you think would be the best choice of file system: ext3 or ext4?
Does ext4 still have potential instability issues, or is it very reliable now?
Is there maybe another filesystem I should look at instead?
Thanks!

ext3's fsck times are pretty slow. I have a 40 GB ext3 and it's painful. I literally grab a cup of coffee while waiting for it to finish. It takes minutes.
My other box is 80 GB ext4 and fsck takes just a couple extra seconds compared to the regular (w/o fsck) boot.
You can tweak both filesystems, depending whether you want to be safe or get extra speed (things like barriers=0) http://www.kernel.org/doc/Documentation … s/ext4.txt

Kernel panic after converting from ext3 to ext4?

I'm running Arch 64 on a Lenovo ThinkPad R61. I did a pacman -Syu this morning and upgraded to 2.6.28-ARCH, among other things. I rebooted to verify that nothing went amiss with the kernel upgrade. Indeed, there appeared to be no problems. I then followed some directions on converting my partition from ext3 to ext4. (I did a tune2fs and then a fsck.) After finishing the fsck, I rebooted to find the following error message:
kinit: Cannot open root device sda2(8,2)
kinit: init not found
Kernel panic - not syncing: Attempted to kill init!
I rebooted twice and got the same result.
What should I do?

see http://bbs.archlinux.org/viewtopic.php?id=38136
i had this prolbem but i resolved
Last edited by ugaciaka (2009-01-16 17:20:06)

Filesystems - ext4 vs XFS on multimedia HDDs

Hi,
I was wondering how does XFS perform in the long run compared to ext4 on strictly multimedia storage hard drivers - where no file is less than 500mb.
I read some benchmarks, and all these tests show XFS in various situations - but I am unable to determine how would this reflect on usage in practice - e.g. one of most important things for me is copying <from> and <to> the hard drive.
I ran some quick benchmarks on my own:
Copying 232.6mb:
XFS - 70mb/s write, 45mb/s read
EXT4 - 69mb/s write, 48mb/s read
JFS - 60mb/s write (little behind), 50mb/s read
So, my question is, is it worth it to run all my multimedia storage partitions on XFS or should I just stick to ext4 since it seems just as fast (at least by my estimate), and is relatively newer and more maintained?

If someone's interested... I tested XFS and ext4 on fastest hard drive I currently have, and tweaked the mount settings on both filesystems. The both partitions are on the same hard drive as shown:
/dev/sda2 ext4 40G 24G 14G 64% /home
/dev/sda4 xfs 172G 733M 172G 1% /media/ST3250410AS
The fstab tweaks are noatime,nobarrier for both, and logbufs=8 for XFS:
/dev/sda2 /home ext4 defaults,noatime,nobarrier 0 1
/dev/sda4 /media/ST3250410AS xfs defaults,noatime,nobarrier,logbufs=8 0 0
At these settings write speed is (copied FROM the same hard drive to sda2/sda4):
ext4 - 70.77mb/s
XFS - 96.92mb/s
Read speed is (copied TO the same hard drive from sda2/sda4):
ext4 - 73.72mb/s
XFS - 83.43mb/s
So in terms of pure read/write speed, XFS still wins when tweaked...
Last edited by karabaja4 (2010-12-27 21:11:57)

Ext3 to ext4 /home upgrade

Hello folks,
I'm thinking on upgrading my /home ext3 partition to ext4, I already read about the new features and performance improvement, also about the little problems, and the bug about the data loss, it not being a problem to me 'cause I have an UPS.
So, do you recomend me to upgrade or wait a little more for any important problem being right now, etc etc.
Also, how do you recommend me to do the switch;
a) upgrade the ext3 partition to ext4
b) backup everything format to ext4 and copy back
Any trick to increase permormance, noatime, data=writeback, etc etc
Thanks for your opinions and excuse my grammar.

All info on performance tricks, etc. can be found in the ext4.txt file in the Documentation folder in the kernel sources.
http://git.kernel.org/?p=linux/kernel/g … xt;hb=HEAD
ext4 is a stable, solid FS that has been in the kernel for two years or so now, even though it's only recently been marked stable.
As for the data loss, it's not a bug. Here's the lowdown. See, *most* filesystems behave in such a way that data is comitted to disk, practically guaranteed, in a very short amount of time. XFS, ext4, and Btrfs all perform delayed allocation in order to be faster. Apps that have been written according to the POSIX standard will be fine with ext4 and those other filesystems. Some apps, however, are written in such a way that if there is a sudden power loss (if the ext4 filesystem suddenly dies), data might be truncated, usually to 0. This is a bug in the _apps_ - the standard makes no guarantee that the filesystem works like ext2/3, ReiserFS, JFS, etc. But since there's a good number of buggy apps, Tso is working on some ugly hacks to make this scenario less likely. What you can do right now is add the 'nodealloc' mount option to your fstab. This will disable delayed allocation. Boom, no more 'bug'. Lower speeds, but still faster than ext3. Kernel 2.6.30 will likely have more efficient hacks that can let you have partial delayed allocation.
Durr. Just read that you have a UPS. So, you're good, most likely
Although, I would only really recommend ext4 if you have particular need of its features - fast fsck, fair performance increase (you likely will not notice it outright), barriers (makes data even less likely to go *poof*, but there can be big performance losses, and cannot be used with device-mapper (LVM, LUKS)), file # limit, etc., OR if you are planning on setting up a new /home anyways and want to spare trouble later. If you're already on another FS and would otherwise not need to do any switching or anything, I'd stick with ext3 for maybe a year.

Ext3+dir_index vs JFS, XFS, ReiserFS. Choice problem

I'm a linux noob.
Going to install Archlinux to new laptop Inspiron 1520
Right now playing with Archlinux on vmware.
I want my laptop be fast, and of course choosing right FS is important in this regard.
Let me sum up all i read so far about different FS.
ext3 vs XFS, JFS, ReiserFS:
- ext3 is most stable, most supported. But also slowest.
- XFS, JFS, Reiser are much faster, but have stability and or support problems.
- ext3 with dir_index is fast, almost as fast as others.
- noatime,nodiratime considerably improve performance of all these FS
So here are my questions.
1. Will ext3 + dir_index + noatime,nodiratime be up to the par with XFS,JFS ?
2. Does disr_index enabled by default on latest Arch or do I have to enable it manually ?
3. What other advantages besides speed JFS,XFS have comparing to ext3 ?

lucke wrote:Fragmentation can be an issue. <snip>....<snip>s impact on performance.
Yes indeed fragmentation can cause a significant penalty in performance, especially if you are copying large, very fragmented files. But for a desktop system people usually deal with smaller files than ones downloaded in large torrents; at least that was my impression for my previous post. The thing about XFS being designed as it is, is that it doesn't handle fragmentation of large files well. Basically, the extensive use it makes of B+ trees make it particularly cpu intensive for working with reads that are non-continuous and hence is particularly hurt when copying highly fragmented, large files. This isn't quite as pronounced in JFS (but the performance hit is there) because it's cpu usage isn't as high as XFS; and it's algorithms are more optimized for working with smaller continuous reads than XFS (to my understanding). This is probably the main reason why XFS has a defragmentor and JFS does not.
One thing that fragmentation of a JFS filesystem will have a major effect on is performance of a VMware virtual machine whose image is highly fragmented on JFS. I mentioned this in the wiki article. If you use VMware with a growing image, I recommend somewhat regular defragmenting of the JFS partition, otherwise the VM will be significantly impeded. I imagine this situation is true for other file systems other than JFS. Also, if you torrent frequently with large files, then I would suggest regular JFS defragmenting in this scenario as well.
Gullible Jones wrote:Re JFS data loss: bug reports have been filed. See here and here.
The first report is most likely due to the fact that JFS journals metadata only. This is also the case with XFS, Reiser, and ext3 (with the popular journal=writeback implementation). Caching data losses like the first bug report seems to describe what has been known to happen with other file systems on linux and not JFS. Nonetheless, JFS has never hidden the fact that it journals metadata only as journaling both metadata and actual file data incurs a big performance hit.
The second bug report could easily be a hardware failure. Indeed with both the log and no inodes being dumped to the lost+found directory, I would not jump to judgment that this was necessarily a JFS issue as that would imply JFS failing in SEVERAL different places. It is more likely that the issue was one with hardware.
As I said before, neither one of these show that JFS conclusively looses files in its own right. If you really require journaling of both metadata and file data, then ext3 is the only option for linux (with no journaling /etc/fstab optimizations); JFS and other journaling file systems don't do this as it significantly reduces performance.
Anyway, I am done going on about this; if people are hellbent on believing JFS looses files, so be it. Personally, I have never had a data loss issue with JFS despite years of use and abuse in the spectrum of possible hardware and software configurations.
Last edited by PDExperiment626 (2007-12-29 16:20:36)

Filesystem ext2/ext3 at Mac OS X

Hi together,
how can i mount a partition with an ext2/ext3 filesystem ?
Thank you and best regards
oelauge

Try using this tool.
(14329)

[SOLVED] Converting the var partition filesystem from ReiserFS to ext4

Hi,
I have a system that still uses ReiserFS for its /var partition. It gives me some performence problems which make me want to convert it to the newer ext4. Can it be done without reinstalling the entire system? and if so, how?
Last edited by Greenstuff (2013-10-05 14:01:41)

Boot to a live environment.
Mount the var partition and copy somewhere or tar it up.
Umount the var partition.
Format the old var partition to ext4.
Mount the newly formatted var partition.
Copy back or untar the archive.
Reboot.
EDIT: Make sure you adjust the fstab in the root partition before you reboot!
Last edited by graysky (2013-10-05 15:14:31)

Best filesystem for external hard drive?

I just bought a Maxtor Basics 1 TB external hard drive. I think the current filesystem it is using is NTFS. Should I stick with it, or should I reformat it to ext3( or something better?). What are the advantages and disadvantages?. Primary use is in linux.

xfs is great for big files, but so is ext4. xfs sucks with small files, ext4 doesn't. ext4 by default offers safer journaling, but it will be easily available only with the next kernel release, which should come soon, and might be regarded as more hazardous than well-tested xfs. Converting a filesystem from ext3 to ext4 is trivial, but you'd have to move the old files around to make them use extents.
I myself have moved my /home partition, holding mostly big files, to ext4 from xfs, but that's because of its better small file performance.

Mounting ext3 root FS as ext4

Hi,
I'd like to move from ext3 to ext4 on my HD, but I'm not yet completely sure about that , so I'd like first to try out the "no conversion" upgrade by mounting my existing ext3 filesystem as ext4.
So I changed "ext3" in my fstab to "ext4", but the system still mounts my ext3 device as ext3. I think the problem resides in klibc and initramfs .
I tried setting the rootfstype= parameter at boot but I get Kernel Panic.
The system is upgraded to lastest version.
Can you help me in getting my ext3 root be mounted as ext4 at boot time?
Thanks
Marcello

Look at the wiki page:
http://wiki.archlinux.org/index.php/Ext … Converting
You did not convert the fs, so it is still mounted as ext3, but used in a ext4-compatible mode. You'll need to convert the fs as described below on the same wiki page to take advantage of the ext4 features and improvements.
Be aware though that there may be some data loss related to some software bugs (such as KDE): http://www.h-online.com/open/Possible-d … ews/112821

Data recovery after filesystem change ntfs- ext4

so here's my story:
i wanted to instal arch on a friend's machine and it was a success. BUT i accidentaly used a wrong partition and changed the filesystem from ntfs to ext4.
normally i would use something to recover my data but the filesystem change bothers me.
is it even possible to recover anything from it?
i have heard that test disk would be able to do this task, but there's a probability of damaging other partitions.
what do i do?
any help is appreciated

jakobm wrote:
robug wrote:BUT i accidentaly used a wrong partition and changed the filesystem from ntfs to ext4.
What exactly did you do? As far as I know, there is no way to 'change filesystems'.
Did you run a mkfs.ext4 on said partition?
the partition has beed formated from ntfs to ext4 while instalation. so it has arch on it at the moment

Need help with formatting a software RAID 5 array with xfs

Hi,
i'm tying to format a software RAID 5 array, using the xfs filesystem with the following command:
# mkfs.xfs -v -m 0.5 -b 4096 -E stride=64,stripe-width=128 /dev/md0
but all I get is the attached error message. It works fine when I use the ext4 filesystem. Any ideas?
Thanks!
http://i.imgur.com/cooLBwH.png
-- mod edit: read the Forum Etiquette and only post thumbnails http://wiki.archlinux.org/index.php/For … s_and_Code [jwr] --

Sorry I numbered them to show the flow of information, this was also just a place for me to store info as I worked through it. I managed to get it to work by creating a partition that takes up the whole drive and is actually 22 GB larger than all the other drives (since I found out that the had root, swap and home partitions that are no longer needed).
I should be able to resize the other partitions without a problem, correct? They're EXT4. Should I unmount the raid array and do them individually, remount the array, let it sync and do the next? Or just unmount the array, resize all of them, mount it and let it sync?

Is it ok to keep /boot or / partitions are reiserfs instead of ext4?

What do you think about using reiserfs on the entire system? Is it ok for /boot and / especially?

WonderWoofy wrote:@milomouse, when was the last time you used btrfs? How were you comparing speeds, was this real world usage (as in how it felt) or are you going off benchmarks (either yours or found elsewhere)? If speed is what really concerns you, and you need TRIM, journaling, etc. wouldn't ir make a whole lot more sense to go with ext4? I have seen the benchmarks around the internets that say that btrfs is oh so much slower than the others, but honestly, I just recerntly switched from a raid0 ext4 across two samsung drives to btrfs on a just one of those, and with day-to-day stuff, I can't tell a bit of difference. Though my boot time did slow down by about 0.3sec (gasp!).
Like I said, I use btrfs on /boot but nothing else at the moment. The last time I used btrfs on a larger partition such as / or ~/ was about 6 to 8 months ago. I admit that's a "long time" in the computer world but it was significant enough for me to finally switch to ext4 at the time. The responsiveness at the time was like night and day, but with current improvements may be negligible today. The most noticable difference was not reading but writing to the disk under btrfs regardless of sync settings. I believe it was COW but I didn't want to disable due to the benefits it held.
Anyway, btrfs may be just as swift now-a-days so it's worth a try on larger partitions if you're willing to compare it. I just found JFS to be very quick and supportive of everything I need in a filesystem as I don't do on-disk backups for / (I use external for this), but for /boot it's handy -- also, I don't automount /boot in fstab so there's less of a chance at screwing it up by accident, I will mount it manually whenever I need to rebuild kernel and copy bzImage.

Kernel 2.6.30 and ext4 file systems - nodelalloc still needed?

Is it true that one does not need the nodelalloc switch in the /etc/fstab to prevent data loss due to an ungraceful reboot/shutdown of an ext4 partition under the new 3.6.30 kernel?

You shouldn't need nodelalloc, yes.
ext4 2.6.30 has code in it that hacks around the most common problems with apps that write data assuming the filesystem exhibits ext3-like behavior. But it's up to you -- if you didn't notice any performance loss, why not keep it?

Filesystems benchmarked: EXT3 vs EXT4 vs XFS vs BTRFS

Similar Messages

Maybe you are looking for