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@xxxxxxxx> 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@xxxxxxxxxxxxx [mailto:
> oracle-l-bounce@xxxxxxxxxxxxx] *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
>
>
>

Other related posts: