linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mihai RUSU <dizzy@roedu.net>
To: Tux mailing list <tux-list@redhat.com>
Cc: <linux-kernel@vger.kernel.org>
Subject: Re: Lots of questions about tux and kernel setup
Date: Mon, 5 Nov 2001 16:11:21 +0200 (EET)	[thread overview]
Message-ID: <Pine.LNX.4.33.0111051607320.8028-100000@ahriman.bucharest.roedu.net> (raw)
In-Reply-To: <Pine.LNX.4.30.0111051429040.18879-100000@mustard.heime.net>

On Mon, 5 Nov 2001, Roy Sigurd Karlsbakk wrote:

> > to answer other "not asked" questions of yours ill point you to :
> > http://www.specbench.org/osg/web99/results/res2000q4/web99-20001127-00075.html
> >
> > as that should help you very much :) (that /proc tweaking its pretty cool)
>
> Thanks!
>
no problem

> Just one thing...
>
> I need redundancy, so I can't go with RAID 0. I thought I'd go with RAID
> 4, to avoid reading the parity info (and thereby wasting time), and still
> have some quite good redundancy.
>
i see
we use raid-5 in production here

> Q: Should I use hardware RAID or software RAID here? I can see they've
> been using a rather large stripe (or chunk) size on the RAID (2MB). The
> RAID controller I planned to use only supports up to 512kB stripes. As I
> said, the files I'm reading are rather large - up to 10GB each, or at
> least 1GB. I'm reading 4-7Mbps (500-900kB) per connection and each
> connection reads only one file. Will a large stripe size help me here?
>

if you got the money i recommend Mylex AccelRAID (www.mylex.com)
they are very well supported on linux and pretty fast too :)

im not a raid expert but i found some interesting information in the
DAC960 docs (/usr/src/linux/Documentation/README.DAC960)

Quote:

For maximum performance and the most efficient E2FSCK performance, it is
recommended that EXT2 file systems be built with a 4KB block size and 16
block stride to match the DAC960 controller's 64KB default stripe size.
The command "mke2fs -b 4096 -R stride=16 <device>" is appropriate.
Unless there will be a large number of small files on the file systems, it
is also beneficial to add the "-i 16384" option to increase the bytes per
inode parameter thereby reducing the file system metadata.  Finally, on
systems that will only be run with Linux 2.2 or later kernels it is
beneficial to enable sparse superblocks with the "-s 1" option.

now i know you will not use ext2 (for data at least) but its a start point
to optimize the RAID and FS (whatever your choice)

i recommend XFS for those large files you have there

----------------------------
Mihai RUSU
"... and what if this is as good as it gets ?"


  reply	other threads:[~2001-11-05 14:10 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-05 12:33 Lots of questions about tux and kernel setup Roy Sigurd Karlsbakk
2001-11-05 13:26 ` Mihai RUSU
2001-11-05 14:00   ` Roy Sigurd Karlsbakk
2001-11-05 14:11     ` Mihai RUSU [this message]
2001-11-05 14:50     ` Michael E Brown
2001-11-05 15:42       ` Roy Sigurd Karlsbakk
     [not found] <Pine.LNX.4.10.10111051119360.13543-100000@coffee.psychology.mcmaster.ca>
2001-11-05 16:47 ` Roy Sigurd Karlsbakk

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=Pine.LNX.4.33.0111051607320.8028-100000@ahriman.bucharest.roedu.net \
    --to=dizzy@roedu.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tux-list@redhat.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).