Re: Where to put RAID (was Re: LVM etc... biggest thread in history)

David Lang (dlang@diginsite.com)
Tue, 30 Jun 1998 15:33:09 -0700 (PDT)


-----BEGIN PGP SIGNED MESSAGE-----

I am thinking ot two basic jobs.

1. connecting multiple chunks together into one "device" for the filesystem to
reside on.

2. running multiple devices throug a blender to provide raid
performance/failover capability.

I see these a seperate enough (plus budget allowing I will take hardware raid
solutions any day, no CPU overhead) to be done in seperate layers. the LVM layer
doesn't care if the devices it is given are raw "old style" partitions, or
sections of a raid array, it would just allocate them as needed to give a
filesystem the space it needs.

There will be a performance hit of some kind for doing an extra level of
management (even if it is done in the filesystem there is at least one extra
pointer ref) so some systems will not want to pay the performance hit of the LVM
(news servers for example) but will still want the raid cpability, other systems
will want the LVM for the size adjustments, but do not need the raid (either
becouse they don't have sutable hardware, or they have hardware raid). In either
case the code for the other capability is dead weight.

The question is which is worse.

additional overhead if all features are turned on (LVM + raid managed seperatly)

or

additional code if features are not used (LVM without raid, or raid without LVM
managed together)

David Lang

On Tue, 30 Jun 1998, Shawn Leas wrote:

> Date: Tue, 30 Jun 1998 18:22:18 -0500 (CDT)
> From: Shawn Leas <sleas@ixion.honeywell.com>
> To: David Lang <dlang@diginsite.com>
> Cc: "Theodore Y. Ts'o" <tytso@MIT.EDU>, "Craig I. Hagan" <hagan@cih.com>,
> Heinz Mauelshagen <mauelsha@ez-darmstadt.telekom.de>,
> Linux Kernel List <linux-kernel@vger.rutgers.edu>,
> mge@ts1.ez-darmstadt.telekom.de,
> Jamie Novak <jnovak@ixion.honeywell.com>
> Subject: Where to put RAID (was Re: LVM etc... biggest thread in history)
>
> On Tue, 30 Jun 1998, David Lang wrote:
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> >
> > how about the following division of responsibility.
> >
> > filesystem
> > needs to know how to grow/shrink on command in the device it is on
> >
> > LVM
> > presents a single device to the filesystem and handles the details of
> > allocating/dealocating sections of lower level devices (similar to the md append
> > mode, but dynamicly adjustable)
> >
> > raid drivers/low level drivers
> > handles the raid specifics (striping, etc) and physical device access.
> >
> > This sort of seperation would keep the raid details out of the LVM (where they
> > are not needed if you have a hardware raid system) and lets the filesystem work
> > on stuff as if it is all on one device (for the cases where the LVM puts
> > todeather chunks from several devices)
>
> It seems natural to have software RAID and striping in the LVM, or at
> least to me. I might be wrong, but having this one "entity" to deal with
> "disks" in a plethora of ways is pretty nice. Remember, LVM is a Logical
> Volume Manager, that in effect "Manages" the way physical "extents"
> translate into logical devices.
>
> Is striping/mirroring/RAID not a behavioral aspect of the above handling?
> Please do not take the question as rheotrical, as I do welcome your idea.
> I just don't fully understand the reasoning behind it. My thoughts were
> that layers have a natural seperation, and I just didn't see it there,
> although your idea might be the "Right Thing To Do".
>
> -Shawn
>
> > David Lang
>
>

-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv

iQEVAwUBNZlnpz7msCGEppcbAQEfmAf9HHFOt3K7eEMnTZhGEuvAnUUsg5bwUdY+
qExHDBgUpGRwMQCNXjfFaLQrkjKtyTFtjJRVZ1nQW684HQMMO/2A5TrVCQkYgCKq
ZxYVoNhEmC9/d8KPXqG/WALAwMwBV0SlIhBtcpt9Zh9VMg/X2dyXjrhejeQ4ADQZ
heON/R2jHE8fyPR8re85Su/ktJqEElwazlD6OXGBSQnOS91e+oPtQB4lP+jS+3N5
xkhUqRL8ZKDAaGyginMIXngLsjfGC0/O2qgsVhRD8oDffzsjKl73DiBQJeblJs8w
XL1PAU6Y8MCQSDUIYjLB81hY4DyPw/QwF2aTyODyV+6HfxYqnRRYbQ==
=gMVl
-----END PGP SIGNATURE-----

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu