linux-admin.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Jorge R . Csapo" <jorge@completo.com.br>
To: Paul Furness <paul.furness@vil.ite.mee.com>
Cc: linux-admin <linux-admin@vger.kernel.org>
Subject: Re: How do I pick the best fs?
Date: Tue, 18 Mar 2003 13:55:31 -0200	[thread overview]
Message-ID: <20030318135531.E11511@completo.com.br> (raw)
In-Reply-To: <1048007186.15881.35.camel@Zebra.vil.ite.mee.com>; from paul.furness@vil.ite.mee.com on Tue, Mar 18, 2003 at 05:06:26PM +0000

Hi Paul, this is not a direct answer to your question, but while reading it
something occurred to me that you may find useful. A few years ago I worked for
a bank and was asked to compare performance between different file servers.
My choices didn't include RAID (we're talking circa 1995 here) but I had to
decide to go with one of a) NFS server and PC-NFS equipped Windows clients,
b) Samba servers and Win 95 clients. The servers would be either Intel or Alpha
processors. After a lot of benchmarks I discovered that the number of
simultaneous clients on any given server mattered far more than the difference
between the servers. For instance, one NT server serving one Win station would
outperform everything else. However, when I hooked around 8 clients the
picture began to change. From 10 to 20 clients Samba was the best choice and
upwards of 60 clients the Alpha processor made enough of a difference that the
bank decided to pay about twice as much for those than it would for comparable
Intel machines.

So, when you run your benchmarks try to test with different numbers of clients
for each situation. It's worth the trouble.

Jorge

assim falou Paul Furness (em 18/03/2003):
> Hi.
> 
> I'm afraid this is a bit of a broad question, but I can't think of a
> better place to ask friendly people for some ideas. :)
> 
> I'm building a new production server. It has a big hardware RAID
> attached, such that linux simply sees a single large SCSI disk (1.4TB to
> start with). I'm using LVM to deal with partitioning (which is so far
> working absolutely perfectly), but I need to choose a file system type
> that will be the optimum for me. Not that it's likely to really matter
> for the purposes of this question, but this thing is build on RedHat 7.3
> + patches, and then I have installed 2.4.20 kernel.
> 
> Oh, I should probably explain that the idea is to have a number of
> partitions on the RAID, each shared separately. The shares will be both
> NFS and Samba.
> 
> The three best looking candidates are XFS, Reiserfs and Ext3. Like
> everyone, I want everything from this system - speed, reliability,
> resilience to failures. Probably the most important single thing is
> speed, but it's a photo finish with reliability. Resilience to things
> like power failures is perhaps less important, since it's on our main
> UPS and I take backups every day. :)
> 
> Ext3 is described as very reliable, resilient, but not the fastest
> around. Both Reiserfs and XFS are described as quick, but I get the
> feeling that they are more experimental.
> 
> So, has anyone actually compared them? Ideally, I'd love to find a nice
> table somewhere on the internet labeled "File systems that Paul is
> testing, with the best shown in red." :) 
> 
> I'm quite happy to do comparisons between them before it goes live, but
> I have never really done this before, so I don't really know how to go
> about it (I guess I'd have to think up a test that does a lot of file
> operations that exceed the size of any and all caches on the machine).
> 
> Even better, I suppose, would be a linux based file system testing /
> bench marking program. However, I know nothing at all about what to look
> for.
> 
> Can anyone make any suggestions?
> 
> Tks.
> 
> Paul.
> 
> 
> -- 
> Paul Furness
> 
> Systems Manager
> Visual Information Lab
> Mitsubsihi Electric ITE BV
> Guildford, UK
>  __________________________________________________________
> |  Fight Spam! Join EuroCAUCE: http://www.euro.cauce.org/  |
>  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-admin" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Jorge R. Csapo
--------------------------------------------------
 /"\
 \ / CAMPANHA DA FITA ASCII - CONTRA MAIL HTML
  X  ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
 / \
--------------------------------------------------
http://www.completo.com.br/~jorge
===========================================
With a PC, I always felt limited
by the software available.
On Unix, I am limited only by my knowledge.
--Peter J. Schoenster

  reply	other threads:[~2003-03-18 15:55 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-18 17:06 How do I pick the best fs? Paul Furness
2003-03-18 15:55 ` Jorge R . Csapo [this message]
2003-03-18 17:48 ` Jamie Harris
2003-03-18 18:24 ` urgrue
2003-03-19 20:15   ` Andreas Happe
2003-03-19 22:08     ` urgrue
2003-03-19 23:01       ` Andreas Happe
2003-03-20 11:47         ` Paul Furness
2003-03-20 12:19           ` Andreas Happe
2003-03-20 15:08           ` Milan P. Stanic

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=20030318135531.E11511@completo.com.br \
    --to=jorge@completo.com.br \
    --cc=linux-admin@vger.kernel.org \
    --cc=paul.furness@vil.ite.mee.com \
    /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;
as well as URLs for NNTP newsgroup(s).