Linux PARISC architecture development
 help / color / mirror / Atom feed
From: "Corné Beerse" <cbeerse@lycos.nl>
To: Grant Grundler <grundler@parisc-linux.org>
Cc: parisc-linux@lists.parisc-linux.org
Subject: Re: [parisc-linux] ext2 vs ext3 on hppa
Date: Fri, 11 Feb 2005 14:08:12 +0100	[thread overview]
Message-ID: <420CAE3C.7090004@lycos.nl> (raw)
In-Reply-To: <20050211071629.GA32318@colo.lackof.org>

Grant Grundler wrote:

> Hi all,
> ext3 perf isn't so good on parisc.

Well, From what I know on the linux filesystem types, I can imagine that ext3 is 
not the fastest among them.

ext2 is a (the?) linux normal filesystem: data storage is straigt-forward and such.
ext3 is basically ext2 with added journalling. For reading, it should be just as 
fast as ext2. For writing it is definitly slower than ext2 since it does ext2 
and journalling. As far as I know, the journalling is added to get additional 
data-safety; the filesystem-check is definitly faster/better than for ext2. I 
expect this is at the cost of writing performance.

I don't know xfs, I expect it to be comparable with reiserfs in that it is a 
journalling filesystem, designed from scratch. For these filesystems, I expect 
better performance than ext3 and, depending on several parameters, even better 
performance than ext2.

Between ext2 and xfs/reiser I expect ext2 to be better for large files and the 
others better for lots of small files.

> I've posted profile data for kernel builds:
> 
> http://lists.parisc-linux.org/pipermail/parisc-linux/2004-November/025196.html
> 
> But not for "tar". I can't find the data I collect before. :^(
> ISTR the culprit in ext3 was the bitmap search using atomic ops.
> On parisc, atomic ops are terrible since it requires a spinlock/op/unlock
> sequence.
> 
> I was asked about tar perf again and decided to post some results.
> If someone tells me which wiki page to add this, I'll pound parts
> of the data below into it.
> 
> In a nut shell, I timed unpacking the linux source tree:
> 
> FS 	real		user		sys
> ext2	2m10.814s	0m53.424s	0m6.084s
> ext3	3m46.577s	0m54.619s	1m34.553s
> xfs	1m22.205s	0m53.952s	0m9.739s
> md0+xfs	1m27.740s	0m54.550s	0m12.885s

This clearly shows, that the filesystems do have some differences in performance 
and all are in system-time, the user-time is comparable.

It would be nice if you can give similar stats for different architectures, 
either within pa-risc or even on other platforms.

> 
> User time is predominantly bzip2 running.

There are several things in comparing filesystems. Some (ext2 I expect) 
filesystems are good in hanldling large files. Some (I expect the journaling 
ones) are good in handling many small files.

With bzip2 running, I expect you use packing or unpacking the kernel-source for 
a test. To get raw figures, better use `tar`, `cp -R` or `dd`. And be sure to 
work from one disk to an other.

> 
> I didn't realize xfs can schedule work better than ext2 on a single disk.
> Adding md striping adds ~6% overhead...that's not so good.
> It's possible I need bigger chunks and that would go away.

I don't know what you mean by mdstripping, If it is something like raid-0 or 
raid-1 (or the combination) then striping is only faster on reading, not on writing.

> 
> I don't know if defaults are comparable between xfs and ext3.
> Is one implementing more or better features by default than the other?

As above: ext3 is ext2 with added journalling. xfs is designed from the ground 
up. I'm surprised to see that ext3 takes 15 times more system-time!

> 
> I'll be looking at mdadm+xfs for future file systems to see
> if I can break it. Or I'll have to live without journaling on
> "stable" build machines. The ext3 "tar" performance is just
> unacceptable.

You'd definitly also peek at reiserfs, Its the default fs used in SuSE linux.

If you intend to re-do your tests, think about the next: To test read speed, `cp 
-r` to /dev/null. To test write speed of small files, tar from the fastest 
read-system. (for large files, just copy from /dev/zero).

> 
> BTW, I get segfaults on the ext3 G

Thats a bad sign...



my 2 cents

CBee
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

  reply	other threads:[~2005-02-11 13:08 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-11  7:16 [parisc-linux] ext2 vs ext3 on hppa Grant Grundler
2005-02-11 13:08 ` Corné Beerse [this message]
2005-02-11 17:47   ` Grant Grundler
2005-02-12 20:11     ` Joel Soete
2005-02-11 14:42 ` Matthew Wilcox
2005-02-11 16:53 ` Grant Grundler
2005-02-11 16:54   ` Matthew Wilcox
2005-02-11 17:18     ` Grant Grundler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=420CAE3C.7090004@lycos.nl \
    --to=cbeerse@lycos.nl \
    --cc=grundler@parisc-linux.org \
    --cc=parisc-linux@lists.parisc-linux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox