lkml.org 
[lkml]   [1998]   [Jun]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Where to put RAID (was Re: LVM etc... biggest thread in history)
Be warned, Lots of disjointed thoughts ahead...

On Tue, 30 Jun 1998, David Lang wrote:

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

Well, ok. Since you are suggesting all forms of RAID be moved from the
LVM to a RAID layer rather than having a RAID "behavior" in LVM, is this
to say there would be functionally no LV RAID behavior modification at the
LVM layer? Mirroring behavior, etc? I imagine it's pretty interwoven,
and changing the behavior means implementing a model completely different
from the one currently working.

There are also certain aspects of performance tuning where an FS might
query the LV for it's logical structure/behavior in order to more
appropriately optimize IO. I think that if RAID personality and LV
personality existed in "different worlds" so to speak, that might make
things like this harder. (maybe I'm missing something. I often do)

Anybody agree that keeping all the eggs in the LVM basket warrents
approval?

> 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

This probably isn't so bad. Some of the LVM concepts are RAID like.
Consider striping this newsfeed LV... What would the role of the RAID
layer be?

Splitting the PVs up.. (duplicated?)
Mapping them... (duplicated?)
Managing policys... (duplicated?)

It sounds like the RAID layer is almost LVM like, just not with VGs, and
PVGs. I'm not really even sure where you percieve LVM leaving and RAID
layer beginning. I guess my confusion leads me to think there might be
duplication of some simple LVM concepts at some level, leading to more
overhead. Of course, I might be misunderstanding what your RAID layer is
providing to userland. (An LV of sorts?)

The RAID layer actually duplicates some of the "overhead" we
would be trying to avoid? Besides, with LVM you have REALLY configurable
alocation policies, that are really lightweight and nice.

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

I bet that the overhead you speak of really isn't all that bad. Heinz, can
you possibly shed some light on this?

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

I wonder, but I suspect it's just too nice a thing to have LVM and RAID
personality together, simply as a behavioral aspect of the LV.

I suspect that those using LVM seriously will also be using at least some
form of RAID. If they do in fact use HW RAID, they still probably want
the LVM to manage things because it's nice to have that flexibility. If
they want to to SW RAID with the LVM, one monolithic entity controlling
things just seems nicer (at least then we wouldn't have huge threads where
we all argue what the LVM -> RAID interaction should *really* be). I
know, rather unscientific, but I can't speak definitively to the
performance issues. I do, however, suspect that it's gonna stay where it
is. It seems lightweight and flexible. This is something I've argued for
constantly. A very "common" sort of resource (LV) with a TON of
configurability on the back side. No strings attatched. This leaves us
with a flexible resource that's *easier* to optimize.

Like I said, I bet Heinz could end this thread in a hurry with some
peircing insight. Don't you?

-Shawn

> 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

\
 
 \ /
  Last update: 2005-03-22 13:43    [W:0.720 / U:0.304 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site