All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Ho <andrewho@animezone.org>
To: David Weinehall <tao@acc.umu.se>
Cc: Dax Kelson <dax@gurulabs.com>,
	Peter Nelson <pnelson@andrew.cmu.edu>,
	Hans Reiser <reiser@namesys.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	ext2-devel@lists.sourceforge.net, ext3-users@redhat.com,
	jfs-discussion@www-124.southbury.usf.ibm.com,
	reiserfs-list@namesys.com, linux-xfs@oss.sgi.com
Subject: Re: Desktop Filesystem Benchmarks in 2.6.3
Date: Tue, 02 Mar 2004 20:30:32 -0500	[thread overview]
Message-ID: <40453538.8050103@animezone.org> (raw)
In-Reply-To: <20040302224758.GK19111@khan.acc.umu.se>

XFS is the best filesystem.


David Weinehall wrote:

>On Tue, Mar 02, 2004 at 03:33:13PM -0700, Dax Kelson wrote:
>  
>
>>On Tue, 2004-03-02 at 09:34, Peter Nelson wrote:
>>    
>>
>>>Hans Reiser wrote:
>>>
>>>I'm confused as to why performing a benchmark out of cache as opposed to 
>>>on disk would hurt performance?
>>>      
>>>
>>My understanding (which could be completely wrong) is that reieserfs v3
>>and v4 are algorithmically more complex than ext2 or ext3. Reiserfs
>>spends more CPU time to make the eventual ondisk operations more
>>efficient/faster.
>>
>>When operating purely or mostly out of ram, the higher CPU utilization
>>of reiserfs hurts performance compared to ext2 and ext3.
>>
>>When your system I/O utilization exceeds cache size and your disks
>>starting getting busy, the CPU time previously invested by reiserfs pays
>>big dividends and provides large performance gains versus more
>>simplistic filesystems.  
>>
>>In other words, the CPU penalty paid by reiserfs v3/v4 is more than made
>>up for by the resultant more efficient disk operations. Reiserfs trades 
>>CPU for disk performance.
>>
>>In a nutshell, if you have more memory than you know what do to with,
>>stick with ext3. If you spend all your time waiting for disk operations
>>to complete, go with reiserfs.
>>    
>>
>
>Or rather, if you have more memory than you know what to do with, use
>ext3.  If you have more CPU power than you know what to do with, use
>ReiserFS[34].
>
>On slower machines, I generally prefer a little slower I/O rather than
>having the entire system sluggish because of higher CPU-usage.
>
>
>Regards: David Weinehall
>  
>




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

WARNING: multiple messages have this Message-ID (diff)
From: Andrew Ho <andrewho@animezone.org>
To: David Weinehall <tao@acc.umu.se>
Cc: Dax Kelson <dax@gurulabs.com>,
	Peter Nelson <pnelson@andrew.cmu.edu>,
	Hans Reiser <reiser@namesys.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	ext2-devel@lists.sourceforge.net, ext3-users@redhat.com,
	jfs-discussion@www-124.southbury.usf.ibm.com,
	reiserfs-list@namesys.com, linux-xfs@oss.sgi.com
Subject: Re: Desktop Filesystem Benchmarks in 2.6.3
Date: Tue, 02 Mar 2004 20:30:32 -0500	[thread overview]
Message-ID: <40453538.8050103@animezone.org> (raw)
In-Reply-To: <20040302224758.GK19111@khan.acc.umu.se>

XFS is the best filesystem.


David Weinehall wrote:

>On Tue, Mar 02, 2004 at 03:33:13PM -0700, Dax Kelson wrote:
>  
>
>>On Tue, 2004-03-02 at 09:34, Peter Nelson wrote:
>>    
>>
>>>Hans Reiser wrote:
>>>
>>>I'm confused as to why performing a benchmark out of cache as opposed to 
>>>on disk would hurt performance?
>>>      
>>>
>>My understanding (which could be completely wrong) is that reieserfs v3
>>and v4 are algorithmically more complex than ext2 or ext3. Reiserfs
>>spends more CPU time to make the eventual ondisk operations more
>>efficient/faster.
>>
>>When operating purely or mostly out of ram, the higher CPU utilization
>>of reiserfs hurts performance compared to ext2 and ext3.
>>
>>When your system I/O utilization exceeds cache size and your disks
>>starting getting busy, the CPU time previously invested by reiserfs pays
>>big dividends and provides large performance gains versus more
>>simplistic filesystems.  
>>
>>In other words, the CPU penalty paid by reiserfs v3/v4 is more than made
>>up for by the resultant more efficient disk operations. Reiserfs trades 
>>CPU for disk performance.
>>
>>In a nutshell, if you have more memory than you know what do to with,
>>stick with ext3. If you spend all your time waiting for disk operations
>>to complete, go with reiserfs.
>>    
>>
>
>Or rather, if you have more memory than you know what to do with, use
>ext3.  If you have more CPU power than you know what to do with, use
>ReiserFS[34].
>
>On slower machines, I generally prefer a little slower I/O rather than
>having the entire system sluggish because of higher CPU-usage.
>
>
>Regards: David Weinehall
>  
>



  reply	other threads:[~2004-03-03  1:30 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-02  4:46 Desktop Filesystem Benchmarks in 2.6.3 Peter Nelson
2004-03-02  4:46 ` Peter Nelson
2004-03-02  7:23 ` Hans Reiser
2004-03-02 16:34   ` Peter Nelson
2004-03-02 22:33     ` Dax Kelson
2004-03-02 22:47       ` David Weinehall
2004-03-03  1:30         ` Andrew Ho [this message]
2004-03-03  1:30           ` Andrew Ho
2004-03-03  1:41           ` David Weinehall
     [not found]             ` <20040303014115.GP19111@khan.acc.umu.se.suse.lists.linux.kernel>
2004-03-03  2:39               ` Andi Kleen
2004-03-03  7:47                 ` Christoph Hellwig
2004-03-03  8:03                   ` Hans Reiser
2004-03-03  8:16                     ` Arjan van de Ven
2004-03-03  9:35                       ` Hans Reiser
2004-03-03 17:29                     ` Hubert Chan
2004-03-04  0:10                       ` Hans Reiser
2004-03-03  6:00             ` Robin Rosenberg
2004-03-03  9:43               ` Felipe Alfaro Solana
2004-03-03  9:59                 ` Robin Rosenberg
2004-03-03 10:19                   ` Felipe Alfaro Solana
2004-03-03 10:49                     ` Christian Mayrhuber
2004-03-03 10:56                       ` Mihai RUSU
2004-03-03 13:58                         ` Hans Reiser
2004-03-04  9:28                     ` Kristian Köhntopp
2004-03-05  1:59                     ` Clemens Schwaighofer
2004-03-05  4:21                       ` cami
2004-03-05 20:52                         ` Mike Fedyk
2004-03-05 22:30                           ` cami
2004-03-07  4:50                             ` Mike Fedyk
2004-03-03 10:24                   ` Mike Gigante
2004-03-03 10:24                     ` Mike Gigante
2004-03-03 13:14                     ` Felipe Alfaro Solana
2004-03-03 14:16                       ` Hans Reiser
2004-03-03 13:42                   ` Hans Reiser
2004-03-03 10:13                 ` Olaf Frączyk
2004-03-03 13:07                   ` Felipe Alfaro Solana
2004-03-03 13:07                     ` Felipe Alfaro Solana
2004-03-04 14:37                 ` [Jfs-discussion] " Pascal Gienger
2004-03-04 20:43                   ` Per Andreas Buer
2004-03-03  6:30       ` Hans Reiser
2004-03-03 23:41     ` Johannes Stezenbach
2004-03-05 18:46       ` Pavel Machek
     [not found]         ` <1078586701.6237.0.camel@redeeman.linux.dk>
2004-03-07 12:15           ` Redeeman
2004-03-16  8:16             ` Vladimir Saveliev
2004-03-06  0:16       ` Chris Mason
2004-03-06  0:16         ` Chris Mason
  -- strict thread matches above, loose matches on Subject: below --
2004-03-02 17:11 Ray Lee
2004-03-05  3:32 Burnes, James
2004-03-05  3:48 ` Clemens Schwaighofer

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=40453538.8050103@animezone.org \
    --to=andrewho@animezone.org \
    --cc=dax@gurulabs.com \
    --cc=ext2-devel@lists.sourceforge.net \
    --cc=ext3-users@redhat.com \
    --cc=jfs-discussion@www-124.southbury.usf.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@oss.sgi.com \
    --cc=pnelson@andrew.cmu.edu \
    --cc=reiser@namesys.com \
    --cc=reiserfs-list@namesys.com \
    --cc=tao@acc.umu.se \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.