View previous topic :: View next topic |
Author |
Message |
schiotz Apprentice
Joined: 20 Jan 2004 Posts: 206 Location: Denmark
|
Posted: Thu Oct 28, 2004 12:46 pm Post subject: Timing file systems for the Portage tree. |
|
|
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
- 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".
- Running eupdatedb (twice, actually).
- Disk use, measured with "df -h" and "du -hs /usr/portage".
- 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 |
|
|
eelke Guru
Joined: 17 May 2004 Posts: 406 Location: Earth, Netherlands, Friesland
|
Posted: Thu Oct 28, 2004 7:04 pm Post subject: |
|
|
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 |
|
|
RinkyDinks_RJ n00b
Joined: 12 Aug 2003 Posts: 42
|
Posted: Thu Oct 28, 2004 7:50 pm Post subject: |
|
|
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 |
|
|
gatiba Guru
Joined: 01 Sep 2002 Posts: 434
|
Posted: Thu Oct 28, 2004 10:53 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
pjv Guru
Joined: 02 Jul 2003 Posts: 353 Location: Belgium
|
Posted: Fri Oct 29, 2004 11:45 am Post subject: |
|
|
Here here! |
|
Back to top |
|
|
stefanwa Tux's lil' helper
Joined: 09 Dec 2002 Posts: 140
|
Posted: Fri Oct 29, 2004 1:28 pm Post subject: |
|
|
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 |
|
|
Petyr Guru
Joined: 08 Jan 2003 Posts: 471 Location: San Diego, CA, USA
|
Posted: Fri Oct 29, 2004 6:13 pm Post subject: |
|
|
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 |
|
|
|
|
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
|
|