> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of MOLNAR Ingo
> Sent: Thursday, November 05, 1998 2:59 AM
> To: [EMAIL PROTECTED]
> Cc: Erik Troan; Stephen C. Tweedie
> Subject: RELEASE: RAID-0,1,4,5 and LVM version 0.90, 1998.11.05
>
>
>
> this is an alpha release of the latest Linux RAID0145 drivers, against
> kernel 2.1.125 and 2.0.35. (a 2.1.127 port will follow as
> soon as 2.1.127
> gets out) Also this package contains a prototype (kernel-space and MD
> based) LVM implementation.
>
> WARNING: we are still not out of alpha status, some of the
> features are
> not widely tested. It should be mostly ok, but a backup never
> hurts ...
>
> you can find raid0145-19981105-2.1.125.gz,
> raid0145-19981105-2.1.125.gz
> and raidtools-19981105-0.90.tar.gz in the usual alpha directory:
>
> http://linux.kernel.org/pub/linux/daemons/raid/alpha
>
> new RAID features/fixes in this release:
> ========================================
>
> = 'raid=noautodetect' boot time option added
>
> = /proc/sys/dev/md/speed-limit to runtime-configure reconstruction
> speed.
>
> = initrd and reboot fixes by Luca Berra <[EMAIL PROTECTED]>
>
> = RAID5.HOWTO by Jakob Ostergaard ([EMAIL PROTECTED])
>
> = the 'negative counter' bugfix
>
> = and varios smaller or bigger things i forgot ...
>
> experimental LVM support:
> =========================
>
> the biggest change is the rewrite to get LVM into MD. This ment the
> rewrite of varios MD pieces, eg. md_arrays[] is gone and mddev is now
> runtime allocated, along with minor device numbers. This enables us to
> utilize the rather scarce minor device number space
> efficiently, which is
> a must for LVM.
>
> the LVM is already tightly integrated with the MD stuff. The RAID
> superblock layer still has to be cleaned up a bit more to serve as a
> generic 'storage container identification layer',
> independently starting
> up both RAID and LVM (or both, or stacked) devices. But we are almost
> there.
>
> the LVM implementation lacks proper user-space support, but
> people who are
> interested and want to comment on the design are welcome to
> take a look at
> lvm_p.h, lvm.h and lvm.c. In raidtools there is an 'mkpv'
> utility, which
> prepares partitions to be added to the LVM:
>
> ./mkpv -f /dev/sdc6
> /dev/sdc6's size: 51892 KB.
> /dev/sdc6's rounded size: 51000 KB.
> creating VG ...
> creating LV 1 ...
> initializing block groups on /dev/sdc6.
>
> [root@hell raidtools]# ./mkpv -f /dev/sdc7
> /dev/sdc7's size: 51892 KB.
> /dev/sdc7's rounded size: 51000 KB.
> creating VG ...
> creating LV 1 ...
> initializing block groups on /dev/sdc7.
> [root@hell raidtools]#
>
> a sample raidtab entry to utilize the above PVs:
>
> #
> # Create an LVM Volume Group out of two Physical Volumes:
> #
>
> raiddev /dev/md0
> raid-level lvm #-volume-group
> nr-raid-disks 2
> persistent-superblock 1
> chunk-size 16
> device /dev/sdc7
> raid-disk 0
> device /dev/sdc6
> raid-disk 1
>
> and after 'mkraid -f /dev/md0', the VG will show up in /proc/mdstat:
>
> [root@hell /root]# cat /proc/mdstat
> Personalities : [linear] [raid0] [raid1] [raid5] [lvm]
> read_ahead 128 sectors
> md0 : active lvm sdc6[1] sdc7[0] 0 blocks<LV1 1/20000
> blocks used>
> unused devices: <none>
> [root@hell /root]#
>
> currently 'mkpv' creates a single hardcoded 80M LV, which is mapped to
> /dev/md9. /dev/md9 can then be used to create a filesystem.
>
> [root@hell /root]# mke2fs -b 4096 /dev/md9
> [root@hell /root]# df /mnt
> Filesystem 1024-blocks Used Available Capacity
> Mounted on
> /dev/md9 50140 52 47500 0% /mnt
> [root@hell /root]#
> [root@hell /root]# cat /proc/mdstat
> Personalities : [linear] [raid0] [raid1] [raid5] [lvm]
> read_ahead 128 sectors
> md0 : active lvm sdc6[1] sdc7[0] 0 blocks<LV1 427/20000
> blocks used>
> unused devices: <none>
> [root@hell /root]#
>
> this Logical Volume can be stopped/started in normal
> raidtools fashion,
> and can be autostarted/root mounted as well.
>
> the kernel side of the LVM support code is mostly finished, one major
> component that is still lacking at the moment is proper
> integration with
> the buffer cache. User-space needs some serios coding and
> properly thought
> out utilities. This release of the LVM code is ment to give people an
> opportunity to comment on the design, before i build too many things
> around it :) The physical layout will almost certainly change in a
> nonmaintainable way.
>
> this LVM implementation differs very much from 'typical' LVM
> implementations (AIX, HP-UX, Veritas), it's a 'block-level
> LVM' (i'm not
> sure wether this term exists at all), with an allocation
> granularity (LVM
> blocksize) of 4K. This design is pretty 'daring' but enables us to do
> advanced block device features like filesystem-independent migration,
> resizing, defragmentation, on-demand storage management,
> software-based
> badblock-handling, snapshotting and multiversioning. But i
> first want to
> finalize (and discuss) the core design (which should already
> provide all
> the 'legacy' LVM operations like spanning a filesystem over arbitrary
> devices, and basic storage management) before adding
> 'applications' to the
> core level.
>
> the LVM implementation does not impact overall RAID stability, people
> using RAID should just disable LVM in the kernel config.
>
> enjoy. Reports, comments, flames, feature-requests welcome.
> Let me know if
> i have missed/forgotten some patch sent to me.
>
> -- mingo
>
I applied the raid0145-19981105-2.0.35 patches to a virgin copy of
2.0.35 and they all succeeded. But, when I try to make the kernel, I
get compile errors. For example, with only striping configured I get
the following:
make[2]: Entering directory `/root/raid/linux/drivers/block'
make all_targets
make[3]: Entering directory `/root/raid/linux/drivers/block'
gcc -D__KERNEL__ -I/root/raid/linux/include -Wall -Wstrict-prototypes
-O2 -fomit-frame-pointer -fno-strength-reduce -pipe -m486
-malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=686 -c -o
ll_rw_blk.o ll_rw_blk.c
ll_rw_blk.c: In function `ll_rw_block':
ll_rw_blk.c:552: warning: passing arg 1 of `md_make_request' makes
integer from pointer without a cast
ll_rw_blk.c:552: too few arguments to function `md_make_request'
make[3]: *** [ll_rw_blk.o] Error 1
make[3]: Leaving directory `/root/raid/linux/drivers/block'
make[2]: *** [first_rule] Error 2
make[2]: Leaving directory `/root/raid/linux/drivers/block'
make[1]: *** [sub_dirs] Error 2
make[1]: Leaving directory `/root/raid/linux/drivers'
make: *** [linuxsubdirs] Error 2
The number of arguments to md_make_request changed from three to two,
but both the prototype and the uses do seem to agree:
igate[p4]:/root/raid/linux/drivers/block# grep md_make_request *
ll_rw_blk.c: md_make_request(bh[i], rw);
ll_rw_blk.c.orig: md_make_request(MINOR
(bh[i]->b_dev), rw, bh[i]);
md.c:int md_make_request (struct buffer_head * bh, int rw)
md.c.orig:int md_make_request (int minor, int rw, struct buffer_head *
bh)
grep: paride: Is a directory
Ideas, anyone?
--
John C. Lellis E-Mail:
[EMAIL PROTECTED]
Consultant Phone : (713) 313-5068
FAX : (713) 313-5193
Aspen Technology, Inc.
Advanced Control and Optimization Division
Software Development
9896 Bissonnet
Houston, TX 77036
