linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Tomasz Chmielewski <mangoo@wpkg.org>
To: LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] dynamic allocation
Date: Wed, 19 Dec 2007 10:23:03 +0100	[thread overview]
Message-ID: <4768E2F7.6000308@wpkg.org> (raw)
In-Reply-To: <476644EF.4030103@gmx.de>

Corin Langosch schrieb:
> Hi!
> 
> I'm using lvm2. Currently I have on big VG (100GB) and several LV for
> VServers each 20GB. So my system is limited to having 5 Vservers.
> 
> Is it possible to tell lvm2 to start with only little allocation and
> dynamically grow the LV? I know I can grow it using the command line
> tools but I want it to happen fully automatically.
> 
> So in terms of comands something like:
> lvcreate --size-max 20GB --size-grow 100MB --size-start 1GB vserver06 data
> 
> So the LV would intitially allocate only 1GB of the VG and allocate new
> space in 100MB as it needs, stopping at a maximum size of 20GB. Of
> course I would then have to make sure the VG has enough free blocks for
> the LVs to grow, but that shouldn't be a problem.
> 
> I think this should technically be possible as software like VirtualBox
> can grow it's image file the same way to. If lvm can't to that, could
> that be done with some kind of loopback device? Which is the best way
> (also in terms of performance) to handle such a setup?

Right now it's not possible (kernel-side).

The best you can do is to use a user-space tool which will monitor a 
given volume, and grow it when needed. Saying that, I'm thinking 
primarily of snapshots. You may see a similar discussion last month - 
"balooning/dynamic snapshots?".


With dynamic non-snapshot volumes there is one significant problem 
added: not only must you grow the volume; you also have to (live-)grow 
the filesystem (ext3, xfs, ntfs, raw volumes serving as partitioned 
disks for virtualised guests etc.) that sits on top of that volume.


Perhaps if some skilled developer considers dynamic volumes for LVM in 
the future (be it snapshots, or normal volumes) a good idea would be to 
allow to create a "sparse volume" (similar to a sparse file, where space 
was allocated, but not actually filled with data yet) which could grow, 
if there is still place on the physical volume (with no space, make the 
device read only).



-- 
Tomasz Chmielewski
http://wpkg.org

  reply	other threads:[~2007-12-19  9:23 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-17  9:44 [linux-lvm] dynamic allocation Corin Langosch
2007-12-19  9:23 ` Tomasz Chmielewski [this message]
  -- strict thread matches above, loose matches on Subject: below --
2007-12-13 11:56 Corin Langosch

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=4768E2F7.6000308@wpkg.org \
    --to=mangoo@wpkg.org \
    --cc=linux-lvm@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).