You say you want "striping", but then you say you only have one volume
defined in the volume group... These two things are mutually exclusive.

The only way to have striping is to have multiple devices. The whole concept
of striping is to put sequential blocks of the logical volume on different
physical devices, so as to spread the I/O load. If you have a single volume,
then striping just yields the same pattern you'd have gotten without
striping: one block following the previous and prior to the next, within the
single volume.

I would conjecture that, since you're talking about mod 54 devices, the
whole idea of striping the data within LVM may be moot, since your minidisks
may or may not be on separate physical disks in any case. There's no such
thing as an actual 3390 mod 54: it is itself emulated within the DASD
hardware using basically the same type of disk you find in your PC.
Depending on the size of those devices, your mod 54 may already be spread
across several different volumes, or several of your mod 54's may reside on
the same physical disk. The point being that you really have no way to know,
unless you get into the internals of your DASD implementation behind the
scenes... And there lies madness.

Striping only makes sense where there is a resource you're optimizing or
maximizing. The only valid reason to strip on 3390 and zLinux would be to
allow more active I/Os at a time, through separate virtual addresses, and
I'm not sure Linux would actually take advantage of that.

You certainly can break your large disk down into four smaller ones,
allocate all of these to a volume group and strip the result. Someone would
have to show me the real, measurable benefit of doing this. I'm not sure
it's worth the effort, since it makes the environment much more complex, and
therefore less stable (IMHO).

Having four logical volumes within a volume group isn't wrong or impossible.
In fact, that's what we're doing here. We create two volume groups, each
with one physical volume (roughly the size of a mod 9, generally carved out
of a mod 27). The first volume group (vg_system) is allocated with swap, /,
/var and /tmp. The second volume group (vg_local) gets /home and /opt, and
possibly /app. The user's application eventually installs in /opt or /app.
The only path outside of LVM is /boot, because something has to be outside
LVM to allow the system to boot.

Does anyone have any data that could confirm that striping to 3390 would be
a performance improvement over a larger, non-striped allocation? And what
about the middle ground: Breaking a mod 54 or mod 27 into smaller pieces and
allocating them to a volume group, unstriped. Would there be a performance
advantage from having more virtual addresses to talk to? Would stripping
improve this advantage, or just complicate it?

I'm open minded enough that I might go back and start doing ours
differently, if someone can demonstrate an advantage...

--
Robert P. Nix          Mayo Foundation        .~.
RO-OE-5-55             200 First Street SW    /V\
507-284-0844           Rochester, MN 55905   /( )\
-----                                        ^^-^^
"In theory, theory and practice are the same, but
 in practice, theory and practice are different."




On 3/13/08 4:50 PM, "Collinson.Shannon" <[EMAIL PROTECTED]>
wrote:

> Yeah, but we only have one disk in the LVM.  And while we want striping
> in place (because we'll be using mod54s with PAV in the near future), at
> the moment we don't have PAV either.  Maybe the real problem is that
> I've got 4 different filesystems (/var, /usr, /opt and /home) in a
> single minidisk with only one "reader" at the moment?
>
> If so, could I fake out linux by chopping the minidisk into 4 (or more)
> minidisks for the LVM, even though they'll still be on one physical VM
> volume?  Or since there's still only a base address for that VM volume,
> will that not matter?

----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Reply via email to