Messages in this thread | | | Date | Tue, 30 Jun 1998 21:36:49 -0500 (CDT) | From | Shawn Leas <> | Subject | Re: 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
| |