Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Timing file systems for the Portage tree.
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Documentation, Tips & Tricks
View previous topic :: View next topic  
Author Message
schiotz
Apprentice
Apprentice


Joined: 20 Jan 2004
Posts: 206
Location: Denmark

PostPosted: Thu Oct 28, 2004 12:46 pm    Post subject: Timing file systems for the Portage tree. Reply with quote

Here are some timings on various file systems used for the portage tree.

I while ago, somebody suggested using a separate partition with ext2
or reiserfs for the portage tree. So when installing a new system, I
made a 1.5 GB partition for the portage tree (the distfiles will go
elsewhere). And once the system was up and running, I tried five
different file systems, on operations which are as relevant as
possible for daily use. I made the following tests


  1. Unpacking the portage tree from a tar file. To reduce any effect
    of the root file system, I placed the tar file on a tempfs
    file system, and I changed the compression from bzip2 to gzip so
    CPU load was negligible. I included the time for a following sync
    to reduce the random effect of whether a sync was occurring during
    the operation: time /bin/sh -c "tar xfz ...; sync".

  2. Running eupdatedb (twice, actually).

  3. Disk use, measured with "df -h" and "du -hs /usr/portage".

  4. Doing "emerge sync". I am on a fast network, and with a portage
    tree from the same morning, network traffic should be minimal.
    The main effect is from downloading the list of files, so I timed
    that manually, and subtracted it. I also calculated the timing of
    the rsync part itself from the output of rsync. Occasionally, I
    could see during the download of the file list that I had got a
    slow mirror, then I pressed Ctrl-C and tried again.


Between each test, I unmounted and remounted the file system to remove
the cache from memory, and actually measure disk access. All file
systems were mounted with the noatime option, and the cron daemon had
been stopped.

Here are the results.

Code:

          tar+   first      2nd/3rd       emerge  whereof
FS        sync   eupdatedb  eupdatedb[1]  sync    rsync   df   du
------------------------------------------------------------------------
ext2      39s    -- [2]     56s           3m40s   1m24s   405M 405M
ext2 [3]  42s    2m14s      48s           3m47s   1m38s   --   --
ext3      1m25s  1m40       48s           3m46s   1m16    437M 405M
reiserfs  24s    1m44s      1m03s         1m59s   45s     130M 341M [4]
jfs       3m38s  3m18s      2m22s         4m39s   2m08s   420M 366M
xfs       2m33s  2m23s      1m20s         3m21s   51s     375M 357M
------------------------------------------------------------------------


NOTES:

[1] For all file systems, eupdatedb was slower the first time than the
following times, obviously it was able to skip something the second
and third time. It was not disk caching, as I unmounted and remounted.

[2] The very first time eupdatedb was run it had to build the whole
database from scratch, this took 23 minutes and was the reason for
repeating the ext2 measurement.

[3] Ext2 was tested first, and some time had passed before I
continued, so I repeated the test after all the others since the sync
time might have increased.

[4] Reiserfs' ability to store small files in the inode is really
significant for the portage tree. But du should not be fooled.


CONCLUSIONS:

For this particular purpose, reiserfs seems superior. This is not
surprising since it has a reputation for being good for "extreme use"
such as a large number of tiny files.

The awful performance of JFS surprises me - did I do something wrong?
I got worried that perhaps it did not handle the noatime mount option
gracefully, so I repeated eupdatedb without that option, but with even
worse results (2m40s), plus unmounting suddenly took some time.


MY SYSTEM:

I ran these tests on an IBM Thinkpad T30 with a 2GHz pentium-4
processor and a 60 GB disk. All file systems were created with the
default options, and mounted with the noatime option. My root file
system is JFS (which worries me slightly now) :-)

I hope this is useful for somebody. In case you think I did something
wrong (for example mounting without the option everyone knows is
essential for file system X) please tell me, and I might try again.

Best regards

Jakob
Back to top
View user's profile Send private message
eelke
Guru
Guru


Joined: 17 May 2004
Posts: 406
Location: Earth, Netherlands, Friesland

PostPosted: Thu Oct 28, 2004 7:04 pm    Post subject: Reply with quote

It would have been nice if you had included reiser4 in the test.

The results for jfs and xfs can be explained by the fact that these filesystems offer different functionality. While reiserfs does only meta data journaling jfs and xfs both do full journaling which for some systems is more important then performance. Also these filesystems are designed to perform well when handling concurrent disk request on multi cpu systems.
Back to top
View user's profile Send private message
RinkyDinks_RJ
n00b
n00b


Joined: 12 Aug 2003
Posts: 42

PostPosted: Thu Oct 28, 2004 7:50 pm    Post subject: Reply with quote

Yeah, I agree. You should make a patched kernel with R4 and run the test again. That would allow us Reiser fans to see the speed differences between 3 and 4.
Back to top
View user's profile Send private message
gatiba
Guru
Guru


Joined: 01 Sep 2002
Posts: 434

PostPosted: Thu Oct 28, 2004 10:53 pm    Post subject: Reply with quote

RinkyDinks_RJ wrote:
Yeah, I agree. You should make a patched kernel with R4 and run the test again. That would allow us Reiser fans to see the speed differences between 3 and 4.


Another vote to this :wink:
Back to top
View user's profile Send private message
pjv
Guru
Guru


Joined: 02 Jul 2003
Posts: 353
Location: Belgium

PostPosted: Fri Oct 29, 2004 11:45 am    Post subject: Reply with quote

Here here!
Back to top
View user's profile Send private message
stefanwa
Tux's lil' helper
Tux's lil' helper


Joined: 09 Dec 2002
Posts: 140

PostPosted: Fri Oct 29, 2004 1:28 pm    Post subject: Reply with quote

I did no benchmarks, but I switched from Reiser4 to ReiserFS yesterday (yes!) and "emerge sync" now takes a lot less time! The whole system feels way more snappier too! I'm just investigating if there was something wrong with my Reiser4 partition, because it's not supposed to be that slower!
Using 2.6.9-nitro2 btw.

Steve
Back to top
View user's profile Send private message
Petyr
Guru
Guru


Joined: 08 Jan 2003
Posts: 471
Location: San Diego, CA, USA

PostPosted: Fri Oct 29, 2004 6:13 pm    Post subject: Reply with quote

One suggestion to your testing method, if you have an extra computer on a local network, try setting it up as an internal RSYNC mirror for the portage tree. This would at least eleminate the chance that it's a slow rsync mirror and should give us a somewhat better idea of what FS is performing best.

Thanks for posting this info!

Petyr
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Documentation, Tips & Tricks All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum