This is true - but then again... raw doesn't cost anything... ...Quick IO and cached Quick IO do :-)
I only raise the point because in these days of lvm's (gui and/or otherwise) and "enterprise" backup products, I often fail to see the "managment difficulties" with raw devices. Cheers Connor --- Gaja Krishna Vaidyanatha <[EMAIL PROTECTED]> wrote: > 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). ===== Connor McDonald http://www.oracledba.co.uk (mirrored at http://www.oradba.freeserve.co.uk) "Some days you're the pigeon, some days you're the statue" __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: =?iso-8859-1?q?Connor=20McDonald?= 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).
