Linux LVM users
 help / color / mirror / Atom feed
From: "Heinz J. Mauelshagen" <Mauelshagen@sistina.com>
To: linux-lvm@sistina.com
Subject: Re: [linux-lvm] What is a good stripe size?
Date: Mon, 18 Jun 2001 12:04:33 +0200	[thread overview]
Message-ID: <20010618120433.C14110@sistina.com> (raw)
In-Reply-To: <1418190000.992819631@dizzy>; from lembark@wrkhors.com on Sun, Jun 17, 2001 at 06:13:51PM -0500

On Sun, Jun 17, 2001 at 06:13:51PM -0500, Steven Lembark wrote:
> 
> >> On Sat, Jun 16, 2001 at 03:29:16PM +0200, Urs Thuermann wrote:
> >> > Using the PVs on sda2 and sdb2 I created a single VG and I want to
> >> > create striped LVs on it now.  My questions is, how large should I
> >> > choose the stripe size to achive optimal performance.  If I choose it
> >> > too large, I will probably loose the win of striping.
> >
> >> You lose the advantage of striping if the stripe size is on the order
> >> of the file size.  You want stripes which will be narrower than most
> >> of the files you will be using.
> >
> > I wonder if you are looking at a single file or general
> > throughput here.
> >
> > For a single file you may gain reading speed (writing is less
> > critical as it is buffered); however with a stripe size below
> > file size you will need to move the heads of both (or even
> > more) disks, increasing latency[1], effectively slowing down
> > reads unless you have fairly large files.
> 
> Assumes that the stripe blocks are not adjacent on their
> respective disk drives.  The smaller stripe may have no
> penalty if the logical blocks are adjacent on the disk.
> 
> One of the main resons for using LVM at all is to avoid
> having to worry about any of this.  If raw speed is a major
> consideration then use hardware RAID5 w/ strip size ==
> I/O block size (e.g., 4 disks w/ 1K chunk and 4K filesystem
> block on linux).  This avoids the "extra read" penalty and
> gives nice, distributed reads.
> 
> > [1] Your seek time rises -- on the average -- the more heads
> >     are in use.  With one head you get 1/3 full-seek time for
> >     a random head and file locations.  With two heads you need
> >     to move both heads, chances are that one of them has a
> >     longer way than the other.
> 
> One advantage of striping is that the seek latency of one
> drive can be used for data I/O on another drive.  If the LVM
> system does any sort of double-buffering then the striped
> system can negate/reduce the seek time.

No double-buffering today :-(
LVM just redirects I/Os to the underlying devices (aka physical volumes).

Regards,
Heinz    -- The LVM Guy --

> 
> This also leaves out the issue of journaled file systems, which
> may have data (or just meta-data) spread out all over the
> place -- leaveing you with fragmented reads even in the case
> of a small file.
> 
> 
> Net result is that depending on CPU, bus, controller and
> disk hardware and their interactins with the file systems
> and particular type of I/O being performned the answer
> becomes "It Depends" :-)
> 
> In 15 years the only method I've found that works consistently
> is to try however many of the recommendations you can before
> comitting to any one of them.  Benchmark them under realistic
> condidtions and one will usually be a bit better.  At that point you
> can 'reverse engineer' why your particular conditions match
> that particular theory -- and probably learn a bit about how to
> improve your system as a result.
> 
> 
> 
> 
> > [4] all disks are 'single point of failure'.  Most file systems
> >     do not like loosing spots all over the place.  But then you
> >     do backup religiously, test your backups and have recovery
> >     plans in place, yes?
> 
> Ah, but it's so much more fun to fiture out how it all works at
> 3 in the morning with 20 users breathing fire down your back!
> 
> 
> 
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Sistina Software Inc.
Senior Consultant/Developer                       Am Sonnenhang 11
                                                  56242 Marienrachdorf
                                                  Germany
Mauelshagen@Sistina.com                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

  reply	other threads:[~2001-06-18 10:04 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <134933704.992803570667.JavaMail.root@boots>
2001-06-17 21:36 ` [linux-lvm] What is a good stripe size? Wolfgang Weisselberg
2001-06-17 23:13   ` Steven Lembark
2001-06-18 10:04     ` Heinz J. Mauelshagen [this message]
2001-06-18  4:07   ` idsfa
     [not found] <134782415.992819826651.JavaMail.root@boots>
2001-06-18 11:19 ` Wolfgang Weisselberg
     [not found] <134718885.992837796416.JavaMail.root@boots>
2001-06-18 10:33 ` Wolfgang Weisselberg
2001-06-21  8:46   ` Joe Thornber
2001-06-22  0:59     ` Wolfgang Weisselberg
2001-06-22  9:49       ` Joe Thornber
2001-06-22 14:25         ` Heinz J. Mauelshagen
2001-06-16 13:29 Urs Thuermann
2001-06-17 18:44 ` idsfa

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=20010618120433.C14110@sistina.com \
    --to=mauelshagen@sistina.com \
    --cc=linux-lvm@sistina.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