Re: ORION num_disks

Hi

Four LUNs are created for ASM usage, due to HBA/SCSI queue depth which can limit concurrent request (such as lun-qeueu-depth in HBA configuration or sd_max_throttle in Solaris) to a single disk from OS view it has been proceeded to create 4 in order to avoid this situation. The other reason is not use huge size LUN for ASM so when more space is requiered you dont have to add another huge LUN.

I dont understand very well what is Orion user guide suggesting, it simply states:

num_disks ==> number of physical disks

Since we are in a virtualized environment I am not sure if it really means the number of physical disks from SAN view or logical disks from OS View that is why my post :-)

The fact is I have tested with 8 and 4 disks for this argument but see no differences in the results so I am not sure how is this argument used internally in Orion and wonder if anyone know if this argument makes any difference at all.

TIA

--
LSC





On Fri, Sep 12, 2008 at 12:40 PM, Mark W. Farnham <mwf_at_rsiz.com> wrote:



>  I'm missing why you think the number is not 1.

>

>

>

> I'm curious why 4 LUNs were created – was it merely to keep the total size

> down for a single LUN?  (Some storage mechanisms parcel out various maximum

> resource amounts per LUN, so there are reasons beyond the size is a single

> LUN getting scary to carve up a stripe set into multiple LUNs. I'm not aware

> of per LUN limits like that on Clariions. If there are some I'm always ready

> to be enlightened.)

>

>

>

> These disks have been linked together as a single interdependent unit of

> i/o. Think about it this way: Can you predict whether any two simultaneous

> i/o actions against this set of 4 LUNs will collide on a physical disk?

>

>

>

> You have a single stripe set. (If by your description you mean the disks

> are pairwise plexed and then striped across the four resulting resilient

> logical drives, and then those are carved into 4 LUNs. It would be possible

> from your description to consider a pair of two resilent drive raid groups.

> Then you would have two independent units of i/o within the Clariion box and

> possibly beyond depending on how the i/o controllers are set up and whether

> sharing capacity on them can be nearly ignored [even with 90% headroom on

> total throughput you'll get some collisions on request initiation.])

>

>

>

> Regards,

>

>

>

> mwf

>

>

>  ------------------------------

>

> *From:* oracle-l-bounce_at_freelists.org [mailto:

> oracle-l-bounce_at_freelists.org] *On Behalf Of *LS Cheng

> *Sent:* Friday, September 12, 2008 5:28 AM

> *To:* Oracle-L Freelists

> *Subject:* ORION num_disks

>

>

>

> Hi

>

>

>

> Does anyone know what value should be used for num_disks argument when

> running I/O stress tests with ORION?

>

>

>

> For example consider I have a RAID Group within an EMC Clariion CX-700 SAN,

> formed by 8 physical disks and striped using RAID 1+0, then from this RAID

> Group 4 LUN are created and presented to the server.

>

>

>

> What is the value for num_disks, 8 or 4?

>

>

>

> TIA

>

>

>

> --

>

> LSC

>

>

>


--
http://www.freelists.org/webpage/oracle-l