From: Andy Sy <andy.sy@gmail.com>
To: LVM general discussion and development <linux-lvm@redhat.com>
Subject: [linux-lvm] Re: putting lvm autodetect into the kernel ala md
Date: Wed, 30 Mar 2005 23:38:16 +0800 [thread overview]
Message-ID: <c23be1c30503300738690039d8@mail.gmail.com> (raw)
In-Reply-To: <20050330065236.GA18365@percy.comedia.it>
Luca Berra wrote:
> >Just like the kernel is now able to autodetect and
> >autoenable md RAID arrays, are there plans to make
> kernel autodetection of md arrays is almost always a
> bad idea, it is far better to use mdadm in user space for that.
Why is this necessarily so? RAID autodetect seems to
avoid a lot of configuration hassles especially when your
root partition is involved. Any horror stories to tell?
> >lvm do the same? (i.e integrate the functionality
> >of vgscan / vgchange -ay,-an into the kernel)
> no, it is an user space task, there is no reason to
> burden the kernel with this.
People have recommended against using an LVM
volume for your root partition citing the hassle of
a rescue disk as being the main reason. If lvm volume
autodetect and enabling were in the kernel, then
this would no longer be the case.
I have a good reason for wanting my root partition
to be a logical volume: this is because I can
install my distro directly into it one single big
logical volume and only have to worry about how
to repartition it later in the game.
Being unable to use a logical volume as root
partition is very inconvenient because you have
to make an early decision regarding which of your
top-level directories (i.e. /usr, /home, /var, /opt, /tmp)
to turn into logical volumes and which ones to
put on physical partitions. Worse, as far as I can
tell, you are forced to allocate one logical volume per
top-level dir. This means you are unable to share
logical volume space among directories for which
it makes sense to (e.g. /opt and /usr), thus you
might find yourself resizing logical volumes more
often than you wish down the line.
If lvm were stable and mature enough, and if the claism
being made for it as having very low overhead area are
accurate, the logical conclusion (no pun intended) would
be for people to eventually stop using physical partitions
and using volume groups from the get-go.
Unless lvm detect/enable functionality were built into
the kernel though, you will always have to live with a
physical partition holding /boot - the case today
with LVM and RAID0, but not RAID1 (from which it is
possible to boot directly off of).
next prev parent reply other threads:[~2005-03-30 15:38 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.11694.1112144246.19557.linux-lvm@redhat.com>
2005-03-30 1:02 ` [linux-lvm] Re: Welcome to the "linux-lvm" mailing list Andy Sy
2005-03-30 6:52 ` Luca Berra
2005-03-30 15:38 ` Andy Sy [this message]
2005-03-31 7:38 ` [linux-lvm] Re: putting lvm autodetect into the kernel ala md Luca Berra
2005-04-01 0:39 Andy Sy
2005-04-01 17:41 ` Luca Berra
-- strict thread matches above, loose matches on Subject: below --
2005-04-01 1:16 Andy Sy
2005-04-01 17:41 ` Luca Berra
2005-04-01 19:59 ` Andy Sy
2005-04-04 22:05 ` Luca Berra
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=c23be1c30503300738690039d8@mail.gmail.com \
--to=andy.sy@gmail.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.