linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marc Bevand <marc.bevand@smartjog.com>
To: linux-raid@vger.kernel.org
Subject: Re: Extend raid 5
Date: Mon, 12 Jan 2004 11:02:42 +0100	[thread overview]
Message-ID: <400270C2.3030009@smartjog.com> (raw)
In-Reply-To: <200401121021.08498.maarten@vbvb.nl>

Maarten v d Berg wrote:
> [...]
> Hi Mike.  I read about LVM some time ago and decided to use that as it seemed 
> to solve my problem of the ever-growing data volume I need to store.
> 
> However, after the initial setup I quickly dropped the LVM idea again since it 
> only _seemed_ to solve my problem. As I understand it, LVM allows the 
> addition of extra volumes but it does nothing at the level of the filesystem 
> which resides on top. So in order to effectively grow my filesystem, which is 
> the ultimate goal of course, I'd need to delete the current FS and make a new 
> -bigger- one. And last time I checked this definitely kills your data.
> 
> Otherwise, adding a 40 GB physical volume to a 120 GB raid5 / LVM set just 
> gives me one 120 GB partition and [room for] another 40 GB partition. 
> There is NO gain whatsoever using LVM here compared to when I would just have 
> added a single 40GB disk all by itself without using LVM in the first place, 
> is there ?
> 
> This has always left me wondering.  Did I miss something (except using some 
> alpha FS-resize code...) ?

This is precisely the point, you have to resize your filesystem so that
the extra space added to your LVM device is used. There are many
options, you can either use a userland tool (resize2fs, resize_reiserfs,
...) for resizing an *unmounted* filesystem, or you can do it in the
kernel (mount -o remount,resize=<size> <device>). As you can see, doing
it in the kernel has the extra advantage of allowing you to resize a
*mounted* filesystem.

Filesystem resizing is more stable than you think, for example the
commercial program Partition Magic is based on resize2fs (but I am not
sure if I can convince you with this example since proprietary software
is evil :P).

-- 
Marc Bevand



  parent reply	other threads:[~2004-01-12 10:02 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-12  0:11 Extend raid 5 buliwyf
2004-01-12  2:13 ` Mike Fedyk
2004-01-12  9:21   ` Maarten v d Berg
2004-01-12  9:57     ` Måns Rullgård
2004-01-12 10:02     ` Marc Bevand [this message]
2004-01-12 10:52       ` Maarten v d Berg
2004-01-12 16:15     ` Guy

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=400270C2.3030009@smartjog.com \
    --to=marc.bevand@smartjog.com \
    --cc=linux-raid@vger.kernel.org \
    /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).