[linux-lvm] More thoughts on Linux LVM+RAID

[linux-lvm] More thoughts on Linux LVM+RAID

[CHUCK_MUNRO]

[-- Attachment #1: BDY.TXT --]
[-- Type: text/plain, Size: 1791 bytes --]


I have been reading the thread regarding Linux RAID and LVM with great interest 
(since joining the list today :-).  Please forgive this new thread ... I still 
need to learn how to use the list properly.

I have been using HP LVM with mirroring for several years, and have come to 
expect this arrangement to be configurable without a lot of fuss on HP-UX 
machines.  For this reason I am very interested in seeing the same 
functionality on Linux.

Let's hope the LVM petition succeeds, but are we not dangerously close to 
Linus' freeze date?

I currently use Linux MD mirroring on my firewall/web-server machine at home, 
but have discovered that recovery from disk faults is NOT painless  :-)    I 
implemented full mirroring of the entire boot process by using a Promise 
FastTRACK IDE RAID card to boot a tiny mirrored DOS C: drive (the card nicely 
provides this in its own BIOS).  From there I use loadlin to boot an initrd 
Linux, which activates a RAID-1 root filesystem, switches to it, and so on 
......

This is soooo UGLY, but it has rescued my firewall twice so far.

I would like to encourage a merge of LVM and RAID (at least RAID-0 and 1), with 
the realization that the ease with which HP-UX boots a mirrored root disk would 
involve a lot of kernel changes in Linux.

One remaining snag would then be to work around the BIOS' inability to 
recognize a secondary boot path if the primary one fails (which HP machines 
have been able to do for many years).  I can't think of any solution here 
except for a Promise-like bit of IDE hardware.  The current crop of SCSI 
hardware-RAID controllers (AMI, Mylex, DPT, etc.) are just too expensive for my 
personal budget.

My 2 cents' worth, anyway.

Sincere thanks for the great work with LVM!

Chuck Munro
chuck_munro@hp.com

Re: [linux-lvm] More thoughts on Linux LVM+RAID

[Douglas R. Floyd]

I am of similar feeling, however I have been using AIX's LVM structure for
about five years now.

I do think the combination of LVM, md, a mechanism for doing hot spares, and
a journalling filesystem would put Linux in the big leagues for doing
ultra mission-critical duties.
-- 
Douglas R. Floyd               | PGP key fingerprints
<dfloyd@fnord.com>             | DSS: 70A06BB5F1C24B1732AD6B0679C2FCB2329E0766
Disclaimer:                    | RSA: 94E90F86BB073368ACA4C9931AF214D5
I speak for myself, not my employer.

Re: [linux-lvm] More thoughts on Linux LVM+RAID

[Luca Berra]

On Wed, Sep 01, 1999 at 04:00:11PM -0400, CHUCK_MUNRO@HP-Canada-om1.om.hp.com wrote:
...
> implemented full mirroring of the entire boot process by using a Promise 
> FastTRACK IDE RAID card to boot a tiny mirrored DOS C: drive (the card nicely 
> provides this in its own BIOS).  From there I use loadlin to boot an initrd 
> Linux, which activates a RAID-1 root filesystem, switches to it, and so on 
> ......
> 
> This is soooo UGLY, but it has rescued my firewall twice so far.
> 
> I would like to encourage a merge of LVM and RAID (at least RAID-0 and 1), with 
> the realization that the ease with which HP-UX boots a mirrored root disk would 
> involve a lot of kernel changes in Linux.

as in HPUX the booting process should not involve a lot of kernel
changes.
HPUX dedicates an area at the beginning of the disk to store the
LIF utilities. booting the kernel is done via the HPUX LIF utility
the HPUX utility can read an HFS filesystem and loads the kernel
from the first HFS partition.
it reads the lvm (boot/root/swap/dump) info form the file rootconf
and passes info to the kernel.
Linux has a standard loader (on x86), LILO which is not able to
read a filesystem, so it has to know the list of phisical sectors
on the disk where the kernel is stored. this is why it must be reinstalled
at every kernel build.
Due to MBR size limits lilo is a multi-stage process:
the mbr loads a boot loader (usually boot.b) and info from the
map file.
The problem with LILO is that it needs to know
the physical geometry of the disk. and the md driver does not supply
this info. a proposed solution was to hardcode the geometry info
in the lilo.conf file. another solution would be to use GRUB, which
can read ext2 filesystems from a BIOS recognized partition (no LVM).

Anyway the only thing that is needed to boot from a mirrored disk
is a better tool than lilo/grub, or a modification of what we have.

> One remaining snag would then be to work around the BIOS' inability to 
> recognize a secondary boot path if the primary one fails (which HP machines 
> have been able to do for many years).  I can't think of any solution here 
> except for a Promise-like bit of IDE hardware.  The current crop of SCSI 
> hardware-RAID controllers (AMI, Mylex, DPT, etc.) are just too expensive for my 
> personal budget.
you have three possibilities here:
1) disk 1 is completely failed, the bios does not recognize it,
	disk 2 becomes disk one and all goes well.
2) disk one works, but the kernel is corrupt, if you configured lilo
	correctly you can use fallback=<other disk> or tell it manually
	to boot the other disk.
3) MBR on disk 1 is corrupt, you'll have to manually disable the
	disk from BIOS (scsi controller firmware)

even on HP machines you can find a bootable but broken lif
and you have to manually specify to boot from the altrenate path.

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