From: Andreas Dilger <adilger@turbolabs.com>
To: Steve Wray <steve.wray@paradise.net.nz>
Cc: linux-lvm@sistina.com
Subject: Re: [linux-lvm] lvm and 'poor mans raid' on heterogenous hard drives!
Date: Wed Feb 20 11:32:02 2002 [thread overview]
Message-ID: <20020220103147.A890@lynx.adilger.int> (raw)
In-Reply-To: <NBBBKLKHMJHIJLHOGAOJIEPAJEAA.steve.wray@paradise.net.nz>; from steve.wray@paradise.net.nz on Wed, Feb 20, 2002 at 06:47:42PM +1300
On Feb 20, 2002 18:47 +1300, Steve Wray wrote:
> > The other problem (as I always complain about whenever people try
> > striping and it doesn't work) is that unless you do large file
> > I/O (as you have seen) you don't get much performance gains. This
> > is because for each small* read you basically have to wait for the
> > maxiumu seek time of all of the disks to do a read. For normal I/O
> > patterns this is really bad.
>
> This is very very true. I'm having second thoughts about having
> all of /var on it. Maybe seperate some of the /var directories
> into their own striped volumes.
In most applications, you are better off to put separate trees each on
their own drive. Usually you only have a single application writing
into each tree (e.g. sendmail writing to /var/spool/{mail,mqueue},
other programs writing to /var/tmp, lpd writing to /var/spool/lpd, etc).
If you have each of the high-volume trees on a separate drive it means
that each app can write at the full disk bandwidth without much seeking,
instead of the striped case where each app needs to seek every drive
for every write.
> But what do you think of the huge drop in performance at file sizes
> of 16M and up (at all block sizes)?
> It goes from 50Mps down to less than 20Mps starting when the file size
> hits 16M? Looking at the figures, it virtually halves.
> Read is even more dramatic from 108213Kps at 8192K files down to
> 14796Kps at 16384K files!
Could be several things - cache size issues, journal size, maybe once
you are reading large enough files and your bus/CPU/cache can't keep
up you need to skip a full disk revolution for each subsequent read...
> > You also have the problem that you are 4x as likely to lose all of
> > your data in this case.
>
> yeah but its only /var, /usr/lib, /usr/share, /tmp, swap that sort of thing.
> I think swap may have been a mistake looking at the benchmark!
Swap is a bad move, since you can just add multiple swap spaces with the
same priority (if you so choose) and it will do the striping for you.
Likewise, you could put each of the above trees on their own drive and
you would probably get better overall performance than striping.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
next prev parent reply other threads:[~2002-02-20 11:32 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-02-19 13:54 [linux-lvm] *** ANNOUNCEMENT *** LVM 1.0.3 available at www.sistina.com Heinz J . Mauelshagen
2002-02-19 14:15 ` tim
2002-02-19 18:11 ` Heinz J . Mauelshagen
2002-02-19 20:54 ` [linux-lvm] lvm and 'poor mans raid' on heterogenous hard drives! Steve Wray
2002-02-19 23:20 ` Andreas Dilger
2002-02-19 23:47 ` Steve Wray
2002-02-20 11:32 ` Andreas Dilger [this message]
2002-02-20 16:02 ` Steve Wray
2002-02-20 18:18 ` [linux-lvm] striping volumes Steve Wray
2002-02-20 18:41 ` [linux-lvm] lvm and 'poor mans raid' on heterogenous hard drives! Rupa Schomaker
2002-02-20 20:59 ` Andreas Dilger
2002-02-21 3:19 ` William Blunn
2002-02-21 10:15 ` Rupa Schomaker
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=20020220103147.A890@lynx.adilger.int \
--to=adilger@turbolabs.com \
--cc=linux-lvm@sistina.com \
--cc=steve.wray@paradise.net.nz \
/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.