linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: "Heinz J. Mauelshagen" <Mauelshagen@sistina.com>
To: linux-lvm@sistina.com
Subject: Re: [linux-lvm] LVM and striping, defragmentation
Date: Wed, 28 Feb 2001 11:15:10 +0000	[thread overview]
Message-ID: <20010228111510.U4361@srv.sistina.com> (raw)
In-Reply-To: <20010226203358.A2504@66bassett.freeserve.co.uk>; from joe@66bassett.freeserve.co.uk on Mon, Feb 26, 2001 at 08:33:58PM +0000

On Mon, Feb 26, 2001 at 08:33:58PM +0000, Joe Thornber wrote:
> On Mon, Feb 26, 2001 at 05:04:41PM +0100, Urs Thuermann wrote:
> > I'd like to experiment with LVM and striping.  The HOWTO at
> > www.linuxdoc.org says in section 8.3 LVM native striping
> > 
> >     Performance notices
> > 
> >     The performance 'gain' may well be very negative if you stripe over 2
> >     partitions of the same disk - take care to prevent that.
> > 
> > 
> > How can I take care of it?  I've seen no option in lvcreate to specify
> > where the PE should be taken from.  If I have a VG with only two PVs on
> > two different disks, will LVM automatically choose PEs from the two
> > PVs instead of one PV?  And what if I have a VG with several PVs on
> > disk A and several PVs on disk B.  How can I "take care to prevent"
> > that LVM does not choose two PEs from the same disk for striping?

Having more than one PV mapped to a physical device is *not* the recommended
production configuration. The only reason why we build in that option is
flexibility in test configurations.

> 
> You have highlighted an area where we want to do more work.
> Specifically we want to write a tool that allows you more control over
> the LE->PE mapping.  The striping allocation will try and allocate
> LE's from two different PV's in the VG.  When you create the striped
> LV just try not to have two PV's on the same disk.  You can always
> disable allocation on an individual PV basis.

Check the lvcreate man page, please.
You can add a list of PV device specials to allocate the PEs from to the
lvcreate command line or use pvchange in order to prohibit allocation on
that PV before using lvcreate.

> 
> > When I resize my LVs in a VG multiple times, I can get some
> > fragmentation, i.e. LVs in the VG are not contiguous.  Is there a tool
> > to defragment LVs, i.e. to swap PEs so that all LVs in the VG are
> > contiguous again.  I read in the man page that the allocation policy
> > can be set to "contiguous", but how can I make LVs contiguous after
> > some creating, removing, and resizing of LVs?
> 
> At the moment it's not easy, you might want to look at the pvmove
> documentation.
> 
> > How much performance loss is to be expected in case of non-contiguous LVs?
> 
> It shouldn't be large, the LE's are normally 4 meg so the seeks to
> different parts of the disk won't be that frequent.  To contrast with
> stripes where the chunk size defaults to 64K, which can cause a lot of
> thrashing if the stripes are on the same disk.
> 
> - Joe
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm

-- 

Regards,
Heinz    -- The LVM Guy --

*** Software bugs are stupid.
    Nevertheless it needs not so stupid people to solve them ***

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

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-02-28 11:15 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-02-26 16:04 [linux-lvm] LVM and striping, defragmentation Urs Thuermann
2001-02-26 20:33 ` Joe Thornber
2001-02-28 11:15   ` Heinz J. Mauelshagen [this message]

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=20010228111510.U4361@srv.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;
as well as URLs for NNTP newsgroup(s).