Hi Waleed & list,
The issue I raised about "queuing" was within the
context of sequential writes to the various "stripe
units" within a striped volume. If you have a 4-way
stripe and there are 4 dirty disk blocks (1 on each
stripe unit) that needs to be written to each of the 4
disks, the LVM-mid-layer should be able to get them
down to their respective disks, independent of one
another, not one after the other. If the dirty disk
blocks are not written independent of one another,
there will be no advantage of "striping" for writes.
And "pure striping" should cater to I/O scalability
for both reads and writes.
Regards,
Gaja
- "Khedr, Waleed" <Waleed.Khedr_at_FMR.COM> wrote:
> HI Gaja & list,
>
> I am trying to find the truth here! I was told by
> the storage group that EMC
> has striping now and this what I'm researching.
>
> Gaja, what you described as a problem during WRITES
> to striped EMC is a
> typical procedure in any striped volumes.
>
> There is a mid layer that has to map logical I/O
> addresses to physical disk
> addresses.
>
> If you are using Veritas LVM then all reads/writes
> requests will be queued
> to the LVM and will do exactly as you mentioned.
>
> There is a queue but the difference is big. You
> have a queue with many
> servers serving the queue requests simultaneously.
>
> Please check powerlink.emc.com
>
>
> Regards,
>
> Waleed
>
> -----Original Message-----
> Sent: Tuesday, April 02, 2002 12:38 PM
> To: Multiple recipients of list ORACLE-L
>
>
> Waleed & list,
>
> To define the terms we have on hand:-
> A contiguous meta volume requires the hyper volumes
> to
> be sequential. A non-contiguous does not require the
> hyper volumes to be sequential.
>
> I want to reiterate again that the concept of "pure
> striping" at the hardware level, is still not there
> in
> EMC, even though you have documentation that claims
> that you do. Let me explain.
>
> When you look at "pure striping", there are 2
> aspects
> to it :-
>
> 1) The read aspect
> 2) The write aspect
>
> Take an example of a 4-way striped volume. The read
> aspect provides us the capability for all 4 drives
> to
> independently spin and service I/O from each of the
> drives. This the EMC device does, after the data has
> been placed on all hypers that support a meta
> volume.
>
> The write aspect needs to offer the same
> functionality. So, if you are writing to 4 distinct
> blocks (each on 1 disk), then each drive should be
> able to write 1 block in an independent fashion.
>
> That is where, the EMC hardware striping is not
> complete. This is because, the 4 blocks that need to
> be written to the "meta volume" with 4 hypers
> (regardless of whether it is contiguous or not),
> will
> happen in "sequential" fashion. Meaning, to write 4
> blocks into the "striped volume", the first block
> will
> be written to the first hyper, followed by the
> second
> block to the second hyper and so on. As you can see
> the blocks that need to be written are queued up, so
> that they are written in a sequential fashion on the
> underlying hypers. This can and will cause severe
> write-intensive I/O bottlenecks.
>
> Why is this implemented this way? No specific
> reasons,
> except, "that is how it is right now". It has been
> rumored that microcode 5x68 or 5x69, will do that.
> Remains to be seen.
>
> So all the EMC "striping" does right now is to
> alleviate the problem of read-intensive operations
> not
> hammering a single drive, provided the data is
> spread
> across all the underlying hypers. I am not very
> familiar with the Engenuity product offering, hence
> cannot comment on that, but from what I have heard,
> it
> is a software-based volume management product.
>
>
> Best regards,
>
> Gaja
>
> --- "Khedr, Waleed" <Waleed.Khedr_at_FMR.COM> wrote:
> >
> > It looks like it's available now.
> >
> > This is from: ResourcePak for Windows Version 3.2
> > Product Guide
> >
> > "Symmetrix Microcode level 5x65 includes support
> for
> > concatenated
> > (contiguous) and striped metavolumes.
> > Noncontiguous metavolumes (including striped)
> > require EMC Enginuity(tm)
> > (5x66 microcode) or higher."
> >
> > Regards,
> >
> > Waleed
> > -----Original Message-----
> > To: Multiple recipients of list ORACLE-L
> > Sent: 4/1/02 5:38 PM
> >
> > Waleed & list,
> >
> > I researched this issue recently and found out
> that
> > the meta volume was "concatenating a bunch of
> hyper
> > volume". As you know, concatenation is NOT
> striping.
> > The hyper volumes get filled with data one after
> > another, eventually giving you the "simulation of
> a
> > striped volume", when all hypers are filled with
> > data.
> >
> > I don't know about the "single-host vs.
> multi-host"
> > addressibility issue. There are plans for
> supporting
> > "true striped volumes" in microcode level 68 or
> 69.
> > From some "reliable sources" that does not look
> like
> > it will happen any time soon. So until then, you
> > should consider created mirrored hyper volumes
> > within
> > EMC (RAID 1) and then create a striped volume
> using
> > Veritas Volume Manager, giving you a RAID 1+0
> > configuration, which is ideal.
> >
> > Best regards,
> >
> > Gaja
> >
> > --- "Khedr, Waleed" <Waleed.Khedr_at_FMR.COM> wrote:
> > > Four years ago the only hardware striping
> > available
> > > on EMC I was aware of
> > > was RAID-S.
> > > Recently researching striping ideas on EMC and
> was
> > > told that we can achieve
> > > raid0+1 hardware striping on EMC.
> > >
> > > I was told that EMC has some layer called
> > > meta-volume that is made of many
> > > other hyper-volumes.
> > >
> > > Told also that meta-volumes could be raid-0
> > > (striped) and it's not a
> > > single-host addressable volume.
> > >
> > > Does anybody know anything about this? Can we
> > really
> > > get a hardware striped
> > > volume using EMC?
> > >
> > > Any limitations there?
> > >
> > > Thanks.
> > >
> > >
> > > Waleed
> > >
> > >
> > > Any views or opinions presented in this email
> are
> > > solely those of the
> > > author and do not necessarily represent those of
> > the
> > > company
> > >
> > > --
>
=== message truncated ===
Gaja Krishna Vaidyanatha
Director, Storage Management Products,
Quest Software, Inc.
Co-author - Oracle Performance Tuning 101
http://www.osborne.com/database_erp/0072131454/0072131454.shtml
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Gaja Krishna Vaidyanatha
INET: oraperfman_at_yahoo.com
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
Received on Tue Apr 02 2002 - 17:28:24 CST