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" <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).