[linux-lvm] Re: putting lvm autodetect into the kernel ala md

[linux-lvm] Re: putting lvm autodetect into the kernel ala md

[Andy Sy]

Luca Berra wrote:

> no, [lvm partition detection and activation] is a user space
> task, there is no reason to burden the kernel with this.

I find that a spurious argument.  The kernel autodetects physical
partitions, so how is that different from detecting logical ones?
From the user's point of view he would want it to happen the
same way.  In fact, given the flexibility and [purported] negligible
overhead of logical volumes, he should not even be bothering
with physical partitions anymore.


-- 
reply-to: a n d y @ n e o t i t a n s . c o m

Re: [linux-lvm] Re: putting lvm autodetect into the kernel ala md

[Luca Berra]

On Fri, Apr 01, 2005 at 09:16:01AM +0800, Andy Sy wrote:
>Luca Berra wrote:
>
>> no, [lvm partition detection and activation] is a user space
>> task, there is no reason to burden the kernel with this.
>
>I find that a spurious argument.  The kernel autodetects physical
>partitions, so how is that different from detecting logical ones?
>>From the user's point of view he would want it to happen the
>same way.  In fact, given the flexibility and [purported] negligible
>overhead of logical volumes, he should not even be bothering
>with physical partitions anymore.

it adds unneded complexyty to the kernel.

L.

-- 
Luca Berra -- bluca@comedia.it
        Communication Media & Services S.r.l.
 /"\
 \ /     ASCII RIBBON CAMPAIGN
  X        AGAINST HTML MAIL
 / \

[linux-lvm] Re: putting lvm autodetect into the kernel ala md

[Andy Sy]

Luca Berra wrote:

> lilo does not read a partition.  all that lilo needs is to
> be able to create a mapping from a file to the physical sectors
> on the drive, and guess the BIOS id of that drive.

... and use BIOS (?) to load in the sectors containing
the kernel, initrd, etc... before passing off execution to it?

Anyway, now I believe I understand what you were trying to get at
earlier:

> confusion between a boot loader (which is the only limitation
> we have in loading a kernel/initrd/initramfs) and what the kernel
> can do.

In order for things to work if /boot resides in a non-physical (e.g.
RAID1, RAID0, lvm, etc...), LILO itself has to know how to read the
contents of /boot off of that type of partition.  Having lvm/md
autodetect on the kernel will NOT help LILO (it will, however,
eliminate the need for an initrd).


> I insist initrd is not an hassle, it is good programming
> practice.  This means code separation between kernel-space
> and user space, and the linux kernel is moving _that_ way.

Yes, I do find myself agreeing with your general sentiments.  The
primary concern, to do away with the need to have a separate
/boot partition, is not helped at all if the kernel can autodetect
lvm partitions.

Dispensing with the need for an initrd is but a secondary concern,
and fact is, I would also say that it brings a lot of flexiblity to
the table.  So no, having lvm autodetect in the kernel is not
what I'm looking for.  What we're looking for is good lvm support
in LILO.





-- 
reply-to: a n d y @ n e o t i t a n s . c o m

Re: [linux-lvm] Re: putting lvm autodetect into the kernel ala md

[Luca Berra]

On Sat, Apr 02, 2005 at 03:59:13AM +0800, Andy Sy wrote:
>
>Dispensing with the need for an initrd is but a secondary concern,
>and fact is, I would also say that it brings a lot of flexiblity to
>the table.  So no, having lvm autodetect in the kernel is not
>what I'm looking for.  What we're looking for is good lvm support
>in LILO.

Christophe patches to lilo help a bit, but there still are limitations.
http://www.saout.de/misc/

-- 
Luca Berra -- bluca@comedia.it
        Communication Media & Services S.r.l.
 /"\
 \ /     ASCII RIBBON CAMPAIGN
  X        AGAINST HTML MAIL
 / \

[linux-lvm] Re: putting lvm autodetect into the kernel ala md

[Andy Sy]

Luca Berra wrote:

>> 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?

> yes, read the linux-raid mailing list for those, i
> am tired of beating the same dead horse.

Well, I'm new to Linux raid, perhaps you can point me
to some of the messages referring to such incidents.
I don't seem to see a lot of them on the raid list and
RAID autodetect seems to work well for me (under the 2.4
kernel).

I'll start believing this when I hear that they've
deprecated the RAID autodetect partition type.

What I DO read about a lot are people recommending
against using lvm on their root partition.


>> People have recommended against using an LVM
>> volume for your root partition citing the hassle of
>> a rescue disk as being the main reason.

> this is just ridicolous fud.

Ehrm... just for the record... that recommendation came
from Heinz, the LVM guy, himself:

"having root on a logical volume needs an initrd which
causes hassle in case soemthing goes wrong at boot and you
don't have an emergency boot media with all necessary sw
(i.e. LVM etc.) on it."

http://www.redhat.com/archives/linux-lvm/2003-February/msg00030.html



Like you, though, I disagree with it - as I've explained earlier,
if you can't use LVM on your root partition, what's the point?

> in what cases you would need a rescue disk?
> are those really different from the cases you'd need a
> rescue disk for a normal partition-table based system.
>
> besides, every live distro on earth now supports lvm
> and can be used as a recovery tool.

Although when you say "every live distro on earth", which
parallel earth would that be?

I invite you to download Slax 4.2.0 (the most current
downloadable version of this popular live CD at the time
of your reply), burn it to CD, and let me know if you are
able to find vgchange and vgscan on it.


> i have been using my root partition as a logical volume
> for several years now.

Several years, eh?  Just curious, which distro are you
using?


>> 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).

> i don't have a separate partition for /boot on my lvm systems.
> the only reason i needed a separate boot partition was when i
> had a system using raid5, so i had to have a separate raid1
> partition for booting.

This sure is news to me.  Which kernel version/boot loader
are you using?  What output do you get when you run 'mount'
or 'cat /proc/mounts' ?


> Reading your arguments it appeare you are mis-informed and
> make a lot of confusion between a boot loader (which is the
> only limitation we have in loading a kernel/initrd/initramfs)
> and what the kernel can do.

With LILO and the lvm in the 2.4 kernel, I am **pretty sure** you
CAN'T boot directly into a lvm root partition.  The kernel (which
is in /boot) *has* to reside in a partition readable by LILO
(i.e. ext2, reiser, RAID 1 md or ataraid but NOT lvm) and be
loaded in from there.

Furthermore, you *have* to make an initrd from which you will have
to run 'vgscan; vgchange -an' from, otherwise the lvm partition will
be invisible to the kernel.  And this is exactly where the hassle
lies and where the rationale comes from for wanting vgscan/vgchange
_functionality_ (not necessarily the programs themselves) in the
kernel like the case with md today.

To reiterate, if lvm incurs as little overhead as it is claimed to,
it makes sense for people to stop using physical partitions and
start using lvm all the time.  That would certainly make Linux more
_friendly_ than XP in this area.



-- 
reply-to: a n d y @ n e o t i t a n s . c o m

Re: [linux-lvm] Re: putting lvm autodetect into the kernel ala md

[Luca Berra]

On Fri, Apr 01, 2005 at 08:39:49AM +0800, Andy Sy wrote:
>Luca Berra wrote:
>
>>> 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?
>
>> yes, read the linux-raid mailing list for those, i
>> am tired of beating the same dead horse.
>
>Well, I'm new to Linux raid, perhaps you can point me
>to some of the messages referring to such incidents.
>I don't seem to see a lot of them on the raid list and
>RAID autodetect seems to work well for me (under the 2.4
>kernel).

i could quote Neil Brown back in july 2001

"autorun/autodetect just doesn't belong in the kernel.  It should be
done in user space.  The only time the kernel should assemble a raid
array itself is for the root device, and this is best done with
md=0,/dev/whatever,etc

If I could start with a clean slate, I would rip out the autodetect
stuff completely.  But lots of people are depending on it so I cannot."

anyway the major issues are:
1) raid autodetect uses only the minor number stored in the superblock
to identify the array components, move a disk from a different machine
to yours and reboot it to enjoy the show
2) raid autodetect will try to start everything it finds, it will not
scale with shared storage, or other complex configurations

>I'll start believing this when I hear that they've
>deprecated the RAID autodetect partition type.

the partition type does not need to be changed

>What I DO read about a lot are people recommending
>against using lvm on their root partition.
Informed people?

>>> People have recommended against using an LVM
>>> volume for your root partition citing the hassle of
>>> a rescue disk as being the main reason.
>
>> this is just ridicolous fud.
>
>Ehrm... just for the record... that recommendation came
>from Heinz, the LVM guy, himself:
>
>"having root on a logical volume needs an initrd which
>causes hassle in case soemthing goes wrong at boot and you
>don't have an emergency boot media with all necessary sw
>(i.e. LVM etc.) on it."

yes, since then initrd has become a standard, but i agree "if you dont'
have ...."

just make sure you do and you are set.


>Like you, though, I disagree with it - as I've explained earlier,
>if you can't use LVM on your root partition, what's the point?
>
>> in what cases you would need a rescue disk?
>> are those really different from the cases you'd need a
>> rescue disk for a normal partition-table based system.
>>
>> besides, every live distro on earth now supports lvm
>> and can be used as a recovery tool.
>
>Although when you say "every live distro on earth", which
>parallel earth would that be?
>
>I invite you to download Slax 4.2.0 (the most current
>downloadable version of this popular live CD at the time
>of your reply), burn it to CD, and let me know if you are
>able to find vgchange and vgscan on it.

never tried slax, actually, i spoke to fast.
just find one that does and you are correct.

>> i have been using my root partition as a logical volume
>> for several years now.
>
>Several years, eh?  Just curious, which distro are you
>using?
Mandrakelinux at the moment, i maintain the lvm2, mdadm and mkinitrd rpm
packages for mandrakelinux.
i used a customized redhat before this.

>>> 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).
>
>> i don't have a separate partition for /boot on my lvm systems.
>> the only reason i needed a separate boot partition was when i
>> had a system using raid5, so i had to have a separate raid1
>> partition for booting.
>
>This sure is news to me.  Which kernel version/boot loader
>are you using?  What output do you get when you run 'mount'
>or 'cat /proc/mounts' ?
that server is no more, i still don't understand what strange things i
said.


>> Reading your arguments it appeare you are mis-informed and
>> make a lot of confusion between a boot loader (which is the
>> only limitation we have in loading a kernel/initrd/initramfs)
>> and what the kernel can do.
>
>With LILO and the lvm in the 2.4 kernel, I am **pretty sure** you
>CAN'T boot directly into a lvm root partition.  The kernel (which
>is in /boot) *has* to reside in a partition readable by LILO
>(i.e. ext2, reiser, RAID 1 md or ataraid but NOT lvm) and be
>loaded in from there.
lilo does not read a partition
all that lilo needs is to be able to create a mapping from a file to the
physical sectors on the drive, and guess the BIOS id of that drive.
LVM1 support has been integrated in lilo a long time ago, there are lvm2
patches around as well.

>Furthermore, you *have* to make an initrd from which you will have
>to run 'vgscan; vgchange -an' from, otherwise the lvm partition will
>be invisible to the kernel.  And this is exactly where the hassle
>lies and where the rationale comes from for wanting vgscan/vgchange
>_functionality_ (not necessarily the programs themselves) in the
>kernel like the case with md today.

I insist initrd is not an hassle, it is good programming practice.
this means code separation between kernel-space and user space, and the
linux kernel is moving _that_ way.

>To reiterate, if lvm incurs as little overhead as it is claimed to,
>it makes sense for people to stop using physical partitions and
>start using lvm all the time.  That would certainly make Linux more
>_friendly_ than XP in this area.

this has nothing to do with the argument you are making.

-- 
Luca Berra -- bluca@comedia.it
        Communication Media & Services S.r.l.
 /"\
 \ /     ASCII RIBBON CAMPAIGN
  X        AGAINST HTML MAIL
 / \

[linux-lvm] Re: Welcome to the "linux-lvm" mailing list

[Andy Sy]

Just like the kernel is now able to autodetect and
autoenable md RAID arrays, are there plans to make
lvm do the same?  (i.e integrate the functionality
of vgscan / vgchange -ay,-an into the kernel)

If lvm really introduces as negligible an overhead
as it is touted to, there really seems to be no
reason to go with 'physical' partitions anymore and
it should go the way of the dodo.  I can see a future
where everyone installs their Linux distros on logical
volumes.

Re: [linux-lvm] Re: Welcome to the "linux-lvm" mailing list

[Luca Berra]

On Wed, Mar 30, 2005 at 09:02:28AM +0800, Andy Sy 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.

>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.

a different thing my be said for kernel level manual configuration
(the md=....) commandline, but i dont' feel the need to implement
a device mapper kernel commandline to achieve this.

L.

-- 
Luca Berra -- bluca@comedia.it
        Communication Media & Services S.r.l.
 /"\
 \ /     ASCII RIBBON CAMPAIGN
  X        AGAINST HTML MAIL
 / \

[linux-lvm] Re: putting lvm autodetect into the kernel ala md

[Andy Sy]

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).

Re: [linux-lvm] Re: putting lvm autodetect into the kernel ala md

[Luca Berra]

On Wed, Mar 30, 2005 at 11:38:16PM +0800, Andy Sy wrote:
>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?

yes, read the linux-raid mailing list for those, i am tired of beating
the same dead horse.

>> >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
this is just ridicolous fud.
in what cases you would need a rescue disk?
are those really different from the cases you'd need a rescue disk for a
normal partition-table based system.
besides, every live distro on earth now supports lvm and can be used as
a recovery tool.

>autodetect and enabling were in the kernel, then
>this would no longer be the case.
why?

>I have a good reason for wanting my root partition
>to be a logical volume: this is because I can
i have been using my root partition as a logical volume for several
years now.

>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).
i don't have a separate partition for /boot on my lvm systems.
the only reason i needed a separate boot partition was when i had a
system using raid5, so i had to have a separate raid1 partition for
booting.
Reading your arguments it appeare you are mis-informed and make a lot of
confusion between a boot loader (which is the only limitation we have in
loading a kernel/initrd/initramfs) and what the kernel can do.

Regards,
Luca

-- 
Luca Berra -- bluca@comedia.it
        Communication Media & Services S.r.l.
 /"\
 \ /     ASCII RIBBON CAMPAIGN
  X        AGAINST HTML MAIL
 / \