ext3 "was supposed to be the "native" Linux filesystem". But the fsync(2)/fdatasync(2) bug with ext3/reiserfs4 exposed by Firefox 3 ("this bug show how nasty can it be when you want to flush a specific file, and it actually flushes everything to disk...") should perhaps make us try something else...Linux n00b wrote:I know Linux changed to ext3 by default for some time already. There must be some good about it.
And JFS is very good.
And I guess though JFS today is not actively developed, it is maintained. But yes, "It's such a pity it's stalled!"
Even Linus seems not to like ext3.
From http://kerneltrap.org/node/14148:
From: Linus Torvalds [email blocked]
To: Ingo Molnar [email blocked]
Subject: Re: [PATCH 00/23] per device dirty throttling -v8
Date: Sat, 4 Aug 2007 09:17:44 -0700 (PDT)
On Sat, 4 Aug 2007, Ingo Molnar wrote:
> > [ my personal interest in this is the following regression: every time
> > i start a large kernel build with DEBUG_INFO on a quad-core 4GB RAM
> > box, i get up to 30 seconds complete pauses in Vim (and most other
> > tasks), during plain editing of the source code. (which happens when
> > Vim tries to write() to its swap/undo-file.) ]
>
> hm, it turns out that it's due to vim doing an occasional fsync not only
> on writeout, but during normal use too. "set nofsync" in the .vimrc
> solves this problem.
Yes, that's independent. The fact is, ext3 *sucks* at fsync. I hate hate
hate it. It's totally unusable, imnsho.
The whole point of fsync() is that it should sync only that one file, and
avoid syncing all the other stuff that is going on, and ext3 violates
that, because it ends up having to sync the whole log, or something like
that. So even if vim really wants to sync a small file, you end up waiting
for megabytes of data being written out.
I detest logging filesystems.
Linus
WOW......From: Linus Torvalds [email blocked]
To: Ingo Molnar [email blocked]
Subject: Re: [PATCH 00/23] per device dirty throttling -v8
Date: Sat, 4 Aug 2007 10:39:56 -0700 (PDT)
On Sat, 4 Aug 2007, Ingo Molnar wrote:
>
> yeah, it's really ugly. But otherwise i've got no real complaint about
> ext3 - with the obligatory qualification that "noatime,nodiratime" in
> /etc/fstab is a must.
I agree, we really should do something about atime.
But the fsync thing is a real issue. It literally makes ext3 almost
unusable from a latency standpoint on many loads. I have a fast disk, and
don't actually tend to have all that much going on normally, and it still
hurts occasionally.
One of the most common (and *best*) reasons for using fsync is for the
mail spool. So anybody that uses local email will actually be doing a lot
of fsync, and while you could try to thread the interfaces, I don't think
a lot of mailers do.
So fsync ends up being a latency issue for something that a lot of people
actually see, and something that you actually end up working with and you
notice the latencies very clearly. Your editor auto-save feature is
another good example of that exact same thing: the fsync actually is there
for a very good reason, even if you apparently decided that you'd rather
disable it.
But yeah, "noatime,data=writeback" will quite likely be *quite* noticeable
(with different effects for different loads), but almost nobody actually
runs that way.
I ended up using O_NOATIME for the individual object "open()" calls inside
git, and it was an absolutely huge time-saver for the case of not having
"noatime" in the mount options. Certainly more than your estimated 10%
under some loads.
The "relatime" thing that David mentioned might well be very useful, but
it's probably even less used than "noatime" is. And sadly, I don't really
see that changing (unless we were to actually change the defaults inside
the kernel).
Linus
"The fact is, ext3 *sucks* at fsync. I hate hate
hate it. It's totally unusable, imnsho."
"ext3 violates that, because it ends up having to sync the whole log, or something like
that. So even if vim really wants to sync a small file, you end up waiting
for megabytes of data being written out.
I detest logging filesystems."
"But the fsync thing is a real issue. It literally makes ext3 almost
unusable from a latency standpoint on many loads. I have a fast disk, and
don't actually tend to have all that much going on normally, and it still
hurts occasionally. "
What is the filesystem preferred by Linus?
Also from Andrew Morton:
So yes, with ext3 we should use "noatime,data=writeback" but then I guess there is no advantage over JFS.From: Andrew Morton [email blocked]
To: Ingo Molnar [email blocked]
Subject: Re: [PATCH 00/23] per device dirty throttling -v8
Date: Sat, 4 Aug 2007 09:51:43 -0700
On Sat, 4 Aug 2007 18:37:33 +0200 Ingo Molnar [email blocked] wrote:
>
> * Linus Torvalds [email blocked] wrote:
>
> > > hm, it turns out that it's due to vim doing an occasional fsync not
> > > only on writeout, but during normal use too. "set nofsync" in the
> > > .vimrc solves this problem.
> >
> > Yes, that's independent. The fact is, ext3 *sucks* at fsync. I hate
> > hate hate it. It's totally unusable, imnsho.
>
> yeah, it's really ugly. But otherwise i've got no real complaint about
> ext3 - with the obligatory qualification that "noatime,nodiratime" in
> /etc/fstab is a must. This speeds up things very visibly - especially
> when lots of files are accessed. It's kind of weird that every Linux
> desktop and server is hurt by a noticeable IO performance slowdown due
> to the constant atime updates,
Not just more IO: it will cause great gobs of blockdev pagecache to remain
in memory, too.
About hdparm I agree with you.
If I had a laptop I'll change it for 254 for sure...Linux n00b wrote:Saving energy is good, but it comes after the hard drive life. If my hard drive dies because of this crazy load cycle, there is no point to save that 1 or 2W energy.
..............................
The "default" setting for power management is crazy.
) here is an article by a guy convinced 
