I don't want to start a "technical religious war"
here. Nevertheles, I am not a great fan of "raw
devices" especially after the advent of comparable I/O
options such as Direct I/O within Oracle which allows
you to keep your file system layout and yet have "raw
device comparable" performance. Plus options such as
Quick I/O and Cached Quick I/O from Veritas provide
similar performance and "ease of maintenance and
management".
Regards,
Gaja
- "Khedr, Waleed" <Waleed.Khedr_at_FMR.COM> wrote:
> So it's great that EMC is offering striping on the
> hardware level that
> should be good idea for implementing striped raw
> device.
>
> -----Original Message-----
> To: Multiple recipients of list ORACLE-L
> Sent: 4/2/02 6:28 PM
>
> 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
>
=== 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 Wed Apr 03 2002 - 11:41:06 CST
