[linux-lvm] Re: root filesystem in lvm

[linux-lvm] Re: root filesystem in lvm

[Stefan Monnier]

[ I apologize if you receive multiple copies, but it seems that
  my earlier attempts didn't make it through.  Is this a closed
  mailing-list ?   - sm ]

A while ago, Michael Marxmeier (mike@msede.com) mentioned:
> However it should be possible to use LILO. As far as i understand
> LILO uses partition relative block numbers to load the kernel image.
> We just need to make sure that they are relative to the dos style
> partition.

How would LILO deal with a kernel image spread over several physical
partitions (or even disks) (in case you not only want a root fs on LVM but
a striped/mirrored/trucmuched one) ?

> If included statically in the kernel the lvm driver could
> execute the equivalent of a vgchange -ay and we should be able to
> mount the root file system.

That would be really neat.  The initrd workaround is just that: a workaround.

> However this will lead to some kernel bloat as some of the code which
> currently resides un user space in lvmlib and vgchange must also be
> present in the kernel.

- how hard would it be ?
- source code bloat:  hopefully, the exact same source code can be shared
  between the kernel and the liblvm/vgchange (I deeply hate code duplication)
- kernel bloat:  how bad would it be ?
  how much of that extra code could be put in __INITFUNC (so that the bloat
  only impacts the on-disk kernel image, but not the in-memory one) ?
  Let's also not forget that the kernel bloat should be measured between
  'linux+lvm+initrd' and 'linux+lvm+lvmroot'.


	Stefan

Re: [linux-lvm] Re: root filesystem in lvm

[Ulrik De Bie]

Hello, 

> How would LILO deal with a kernel image spread over several physical
> partitions (or even disks) (in case you not only want a root fs on LVM but
> a striped/mirrored/trucmuched one) ?
Mirrored would not be such a complex thing I guess, as it simplifies to an
image on one of the mirror partitions. Important is to realise that as far
as lilo is concerned, only the partition where the boot image resides is
important (mostly the partition where /boot resides or even the /boot 
partition).
Then it is up to the kernel to find the necessary code to mount the root
partition and start init.
 
Kind regards,
winmute

Re: [linux-lvm] Re: root filesystem in lvm

[Luca Berra]

On Wed, Jun 02, 1999 at 06:43:23AM -0400, Stefan Monnier wrote:
> How would LILO deal with a kernel image spread over several physical
> partitions (or even disks) (in case you not only want a root fs on LVM but
> a striped/mirrored/trucmuched one) ?
Hard, real hard, lilo uses only bios calls, and in 512bytes
you just cannot fit anithing better, all other os that use lvm
have a /stand partition at the beginning of the disk,
it can be mirrored but it must necessarily be contiguous

> > If included statically in the kernel the lvm driver could
> > execute the equivalent of a vgchange -ay and we should be able to
> > mount the root file system.
> 
> That would be really neat.  The initrd workaround is just that: a workaround.

i personally love modular kernels, so i'd use initrd anyway, but
i agree vgchange -a y could be handled by the kernel.

but i also believe that this would be easier to debug/mantain in
user space.
L.

-- 
Luca Berra -- bluca@comedia.it
    Communications Media & Services S.r.l.

[linux-lvm] Re: root filesystem in lvm

[Stefan Monnier]

A while ago, Michael Marxmeier (mike@msede.com) mentioned:
> However it should be possible to use LILO. As far as i understand 
> LILO uses partition relative block numbers to load the kernel image. 
> We just need to make sure that they are relative to the dos style 
> partition.

How would LILO deal with a kernel image spread over several physical
partitions (or even disks) (in case you not only want a root fs on LVM but
a striped/mirrored/trucmuched one) ?

> If included statically in the kernel the lvm driver could
> execute the equivalent of a vgchange -ay and we should be able to
> mount the root file system.

That would be really neat.  The initrd workaround is just that: a workaround.

> However this will lead to some kernel bloat as some of the code which
> currently resides un user space in lvmlib and vgchange must also be 
> present in the kernel.

- how hard would it be ?
- source code bloat:  hopefully, the exact same source code can be shared
  between the kernel and the liblvm/vgchange (I deeply hate code duplication)
- kernel bloat:  how bad would it be ?
  how much of that extra code could be put in __INITFUNC (so that the bloat
  only impacts the on-disk kernel image, but not the in-memory one) ?
  Let's also not forget that the kernel bloat should be measured between
  'linux+lvm+initrd' and 'linux+lvm+lvmroot'.


	Stefan