[linux-lvm] What is a good stripe size?

[Heinz J. Mauelshagen]

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 at 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 at Sistina.com                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-