5 ms·
Xfs is still faster but ext4 is catching up on large file creation
- gaius 16y agoThis is astonishing. XFS is from 1994...
- nodata 16y agoXFS had a different use case. Pull the plug on XFS and you have problems.
- paines 16y agoWhat would that be ? I am really interested to know. Right now I am running EXT4 on an SSD in my notebook. It performs well. Sometimes, after a suspend , I get a load of EXT4 error messages which are stalling the whole notebook. Hard resseting it, makes the error disappear. Up to now, no data loss.But anyway, this makes me a nervous and I am not sure if it is due to Kernel, SSD, Ext4 or the combination of all/any of them. I guess XFS is way out of my use point, but anyway, an option is an option.
- nodata 16y agoXFS gets higher performance in certain uses cases because it makes assumptions. One of the assumptions is that the power won't go down. ext4: what errors are you getting? I've not seen any so far.
- paines 16y agoI was getting(IIRC) ext4_orphan_cleanup:deleting unreferenced inode XXXXXX messages, one after another after another, and always after a suspend. I waited a few minutes, which made me very nervous. No inputs would take actions besides MagicSysKey->Sync+Umount+Boot. I had this like 4-5 Times.
- iuguy 16y agoAdditionally XFS was built for what (in 1994) were big files, in the order of megabytes upwards.
- dmm 16y agoAll high-performance filesystems assume the power won't go out and lose data if it does. If this matters to you, learn how to use fsync.
- jerf 16y agoSuspends and hibernates do not count as the power going out. If they act like you've simply yanked the plug, something is wrong with the kernel somewhere.
- dmm 16y agoI'm not sure what you are referring to. Are you saying that XFS loses data on suspends? EDIT: Ok I see what's going on. paines is having problems with EXT4 and suspends. I wasn't talking about that. I was responding to nodata's XFS losing data fud.
- mansr 16y agoThat is a misunderstanding. All reasonably performing filesystems lose data if you pull the plug. The difference with XFS is that it buffers writes more aggressively than e.g. ext3, so the amount of lost data may be greater. Properly written apps fsync() any precious data anyway, so this is not an issue. The notion that XFS is unreliable probably stems from the way such lost buffered data has historically been handled. Because XFS allocates the space ahead of actually writing the data, files with unwritten data at a reset could have visible zero-filled blocks after recovery whereas ext3 would simply truncate them. In both cases the data was lost. Since a while back, unwritten extents like these are detected and trimmed back, so now XFS behaves more like most other filesystems. There are still more buffered writes floating about, of course, so the same precautions are still required.
- rbranson 16y agoSo what you're basically saying is with a modern kernel, if you pull the plug on XFS or EXT3/EXT4, to the end user, they are equivalent?
- mansr 16y agoAll of them lose data. XFS risks losing more data than ext3. I don't know how ext4 behaves. A more important aspect is how well the filesystem recovers from having the plug pulled, and here they all do well. Once written to disk, data is stable in all of the mentioned filesystems. This is in contrast to non-journalling ones where an unclean shutdown can render the on-disk data inconsistent and difficult to recover.
- nodata 16y agoYes, so iirc XFS will end up corrupting the data, extN will point you at the old data...
- ams6110 16y agoPeople did have good ideas in 1994.
- gaius 16y agoWell quite - ideas that others are struggling to match in 2011.
- adamzochowski 16y agoI wonder when will ext4 support file systems above 16tb (limit from 4k clusters with 32bit addressing).
- didip 16y agoMore comparisons and benchmarks are available here: http://free.linux.hp.com/~enw/ext4/2.6.36-rc6/ http://free.linux.hp.com/~enw/ext4/2.6.36-rc6/