Continuing the earlier discussion about low latency and Ingo Molnar’s voluntary kernel preemption patch, the conversation moved onto the affect a filesystem can have on latency. Specifically, 2.6 maintainer Andrew Morton noted that ReiserFS was known to have some latency issues in both 2.4 & 2.6 kernels.
Linux: Low Latency and Filesystems
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
This brings a question to my mind; with lower latency on a HD in a laptop, could one get better battery performance? For example, the anticipatory I/O scheduler, as I understand it, gets some performance enhancements by keeping the amount of physical movement of the reader head to a minimum. Could the reduced physical movement result in less power used? I guess, though, that most HD power usage goes toward actually spinning the disk.
More on topic, it’s interesting that they talk of ext2, a fairly bare-bones, few-features FS, getting good latency performance, ext3 getting medium latency (note that it’s just ext2 with journalling, basically), and Reiser gets high latency, while having a lot of features. However, despite the latency issues, Reiser is often said to be a good performer, as-fast-as or faster-than ext3, depending on the type of work it’s doing. It makes link latency with features, as a kneejerk reaction.
Then again, I know practically nothing of FS’s 🙂
Yes, the anticipatory scheduler could possibly lower power usage by reducing head movement.
However, the latency they are talking about is *scheduling* latency: ie. when a realtime task is woken up, how long before it is allowed to get onto the CPU? For some audio users, the requirement is on the order of about 300 microseconds.
What has this got to do with filesystems? Well nothing really that is specific to filesystems; however, maximum scheduling latency is typically bounded below by the length of time spent in a single critical region (basically: lock hold times), and it just so happens that these filesystems can have quite large lock hold times, and hence the focus on them.
I use ReiserFS because it supposedly performs on par with Ext3, but outperforms Ext3 on smaller files. Is this accurate?
Also… what are the benefits of having a Journaled FileSystem? And have these benefits been utilized by the popular desktop environments and apps?
Are there any reasons why I *shouldn’t* go the classic ext2 route?
but I would like know what’s best FS for low cpu usage and files under 10 megs.
The benefit is that you don’t have to run scandisk/fsck when your computer crashes.
As to your performance question regarding ReiserFS, I seem to recall that the main case for ReiserFS was large directories (i.e. thousands of things in a single directory). Typically directories with large numbers of objects tend to contain small objects. Also the Reiser team focussed on optimisations of the small file case. These comments may not be entirely accurate though, so if you really need the correct answers, see their web-site.
Journalling (in context) means keeping a log of the changes you have made (to your FS, DB, or whatever) in addition to actually making them. This enables you to examine the log and the FS/DB/whatever in the event of a failure and return it to a sane state (i.e. with the last operation either completed or reverted).
This means that things like fsck after a crash only needs to examine the changes in the log (typically only the last few) to check that they have been applied correctly (or revert them if they haven’t). This means that, in the event of a crash, you are less likely to require a full fsck which can take hours on new very-large discs. It is also possible (using extrenal journals, etc) to reduce the chance of data loss, though if you need to ask the question you asked, you probably aren’t in a situation that would be very useful.
As to the benefits being utilised, there is nothing for userspace to do. A journalled FS should make no difference to apps, etc. Some of the other features typical in such file systems (Extended and Security Attributes, Access Control Lists, Real-Time Volumes, and various other things) are very-much application oriented and under used, though on Linux, many/most of these features are still under fairly heavy development.
If you don’t see the added safety provided by journalling as a good enough reason, and you don’t use any of the other features (EA, SA, ACL, RT Volumes, etc) then ext2 is fine. I certainly prefer it to the various spawn of UFS.
Appologies for the double posts.
Yes, the anticipatory scheduler could possibly lower power usage by reducing head movement.
So could a lot of buffering. Depending on the amount of RAM and the work-load you might be able to reduce power consumption by tuning the swappiness of the kernel and inducing lots of pre-caching and/or using a very large read-ahead (depending on the work-load).
I suppose one might call it some form of auto-ram-disc-ification 🙂
A lot of the power a laptop uses comes from the Display. That’s why even though Mac logic is a lot more efficient than Intel/AMD, the laptop only gets an hour or two extra runtime.
Non-native speakers of a language have an advantage in that their learning is more formal and organized that native language speakers.
I rarely meet a non-native speaker who can’t speak english far better than a native one.
Thats kind of strange regarding Reiser FS. Every in depth test of FSs on Linux has shown XFS and Reiser to practically be neck and neck, while ext3 is getting destroyed by them.
I noticed that Fedora Core 2 defaults to the ext3 filesystem when Suse 9.1 personal uses reiserFS. It could be assumed that RedHat is not ready to move to reiser bringing up a question of whether or not its up to par.
… how IBM’s JFS performes in latency side. That’s what I use and been very happy with it, lightning years faster than Ext3 and never fallen down. Very reliable.
it messed up my file system once and everything went all weird. All the apps looked all over the place. It was really quite strange.
Anyway, I use ext2 now. It’s tried and tested and rock hard stable. If I ever did a reinstall I might choose ext3 but I’d say that my hardware will bork before my Debian will.
I wonder if these speed differences actually matter on a Desktop system. Surely they’d only matter on a huge server where there’s a lot of disk IO.
Anyway, I use ext2 now. It’s tried and tested and rock hard stable. If I ever did a reinstall I might choose ext3 but I’d say that my hardware will bork before my Debian will.
I’ve lost a few ext2 partition when a machine comes back on after a power outage. Two wildly different machines with wildly different kernels (2.0.x and 2.2.x, I think, but I seem to remember more recent ones too).
Anyways, I wonder if any of these benchmarks make use of xfs’ realtime options. It looks like it made it to the linux version when xfs version 1.3 (Oct 2003) was released. It looks like you’d have to modify the program to set the realtime flag on a file before writing, so I suspect not.
http://www.redhat.com/archives/fedora-test-list/2004-July/msg00034….
The ext3 have almost a perfect record <bold>with the write cache off</bold>
<quoe>what’s best FS for low cpu usage and files under 10 megs.</quote>
Seems like JFS shall offer you the best compromise.