headers
Boddula, Shashi Kanth (HP-SW-LIT | 26 Apr 2013 09:11
Picon
Favicon

Creating mirror volume takes lot of times

VxVM 5.0.3.

 

Creating a 2 TB mirror volume taking almost a quarter day (vxassist -g dg make vol 2000g layout=mirror nmirror=2 mirror=enclr ….)  with drl and fastrsync options.

 

#vxtask

Work time: 7 hours, 8 minutes, 12 seconds (26:54 remaining)

 

Just want to check whether it is common behavior to take this much time to create mirror volumes or this refers to any bug or upgrading to 5.1 is a better option.

 

 

Thanks & Regards,

Shashi Kanth

<div>
<div class="WordSection1">
<p class="MsoNormal">VxVM 5.0.3. <p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">Creating a 2 TB mirror volume taking almost a quarter day (vxassist -g dg make vol 2000g layout=mirror nmirror=2 mirror=enclr &hellip;.)&nbsp; with drl and fastrsync options.
<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">#vxtask<p></p></p>
<p class="MsoNormal">Work time: 7 hours, 8 minutes, 12 seconds (26:54 remaining)<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">Just want to check whether it is common behavior to take this much time to create mirror volumes or this refers to any bug or upgrading to 5.1 is a better option.<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">Thanks &amp; Regards,<p></p></p>
<p class="MsoNormal">Shashi Kanth<p></p></p>
</div>
</div>
Permalink | Reply | 3 comments |
headers
anna cheng | 7 Feb 2013 13:44
Picon
Favicon

(no subject)

<div><div>
<a href="http://www.bandenwerbung.biz/xkmlbyn/4j9yq?7ddwqhtiqiq8e93a6t3j">http://www.bandenwerbung.biz/xkmlbyn/4j9yq?7ddwqhtiqiq8e93a6t3j</a><br><br><br><br><br>anna cheng<br><br><br><br><br><br><br><br><br><br>http://yahoo.com<br>%.1fcd1ahmd5<div></div>
</div></div>
Permalink | Reply | 0 comments |
headers
Omer Faruk SEN | 20 Jan 2013 13:36

vmware test setup

Hi,

I want to have a test environment to see  veritas on rhel6. I want to
see both vxvfs and veritas cluster suite so quick way to have a test
environment is to use vmware and vmware shared disk. So

1) Does vmware supported on veritas cluster and veritas volume manager
2) Which product should i use to test both cluster and shared file
system ( vxfs)

Regards.
Permalink | Reply | 3 comments |
headers
Anthony Herr | 15 Jan 2013 16:10
Favicon

SFCFS and SFRAC are not included in the SFHA 6.0.2 Linux release

We have created a technote that clarifies the lack of support for CFS or Oracle RAC within the SFHA 6.0.2 release.

There are primarily two changes in this release:

1)      VCS Application Configuration Wizards

2)      Support for VMDK disk with the introduction of a new VMware Disk Agent

 

These changes are in VCS as no new functionality is delivered in Storage Foundation in this release.

 

Please review this technote and pass it along to your customers to prevent any confusion on the contents of the SFHA 6.0.2 release and the supported configurations:

 

http://www.symantec.com/business/support/index?page=content&id=TECH201650

 

Regards,

Anthony

<div><div class="WordSection1">
<p class="MsoNormal"><span lang="EN-IE">We have created a technote that clarifies the lack of support for CFS or Oracle RAC within the SFHA 6.0.2 release.<p></p></span></p>
<p class="MsoNormal"><span lang="EN-IE">There are primarily two changes in this release:<p></p></span></p>
<p class="MsoListParagraph"><span lang="EN-IE"><span>1)<span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><span lang="EN-IE">VCS Application Configuration Wizards<p></p></span></p>
<p class="MsoListParagraph"><span lang="EN-IE"><span>2)<span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><span lang="EN-IE">Support for VMDK disk with the introduction of a new VMware Disk Agent<p></p></span></p>
<p class="MsoNormal"><span lang="EN-IE"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-IE">These changes are in VCS as no new functionality is delivered in Storage Foundation in this release.<p></p></span></p>
<p class="MsoNormal"><span lang="EN-IE"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-IE">Please review this technote and pass it along to your customers to prevent any confusion on the contents of the SFHA 6.0.2 release and the supported configurations:<p></p></span></p>
<p class="MsoNormal"><span lang="EN-IE"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-IE"><a href="http://www.symantec.com/business/support/index?page=content&amp;id=TECH201650"><span>http://www.symantec.com/business/support/index?page=content&amp;id=TECH201650</span></a><p></p></span></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">Regards,<p></p></p>
<p class="MsoNormal">Anthony<p></p></p>
</div></div>
Permalink | Reply | 0 comments |
headers
Colin Yemm | 19 Dec 2012 19:45
Picon

Re: Encrypted CFS Recommendations

Hey y'all,

My customer is currently using SFCFS 5.1 with Vormetric file system
encryption, and not having any issues there. They are trying to
implement SFCFS 6.0.2 on Linux and running into HUGE issues with the
VxFS CFS and Vormetric. Vormetric has recommended they go to an NFS
share ... the reason they came off of an NFS share in the first place
was performance ...

Ideas? Comments? Other CFS or encryption products or both to look into?

Thanks

Colin
Permalink | Reply | 0 comments |
headers
przemolicc | 3 Dec 2012 09:11

Stability of Veritas 5.1/6.0 compared to 5.0MP3

Hello,

we have been using SFORA 5.0MP3 for quite long time. Since there is 5.1 and 6.0
for some time we are considering upgrade. Can anybody share his/her experience
about stability of 5.1 and 6.0 compared to 5.0 (MP3) ? The stability is the most
important for us and that is what concernes us.

Regards
Przemyslaw Bak (przemol)
Permalink | Reply | 3 comments |
headers
Neil Swallow | 29 Nov 2012 17:35
Favicon

Re: EMC VMAX with VxVM 5.0

Sebastien,  thanks for the reply

Yes, I made the filesystem on /dev/rdsk/c3t50000974081A7118d1s0     There
is currently just one path from the server whilst we do the migration so I
had to use the -f on the disable command as you suggest.  This eliminated
vxdmp and vxvm in my mind but EMC weren't convinced - hence these emails.
As of a few minutes ago I think we've now persuaded them to stop pointing
the finger (though I have to say even I still find it a bit odd how much
worse things appeared with a vxfs filesystem than a UFS filesytem).

We patched the server as a result of gathering pre-req's from EMC (rather
than running any tools) but we've run EMCgrab at the request of EMC after
logging the call with them and they've highlighted a few things that needed
setting (like the ssd... stuff but are not too forthcoming on the actual
values to use,  I'm not familiar with the "+HEAT" bit though - I'll have a
google of that.

We set these after some digging around the internet and any EMC doc's we
could find.
forceload: drv/ssd
set ssd:ssd_io_time=0x3c
set ssd:ssd_max_throttle=20
set fcp:ssfcp_enable_auto_configuration=1

We also set these in qlc.conf after some digging around
hba1-execution-throttle=20;
hba1-login-retry-count=8;
hba1-port-down-retry-delay=0;
hba1-connection-options=1;
hba1-fc-tape=0;
hba1-persistent-binding-configuration=1;
hba1-fast-error-reporting=0;

(restricted it to hba1 as we didn't want to impact the HDS access that is
still perfectly OK).

None of this has made any difference so far.
thanks,
Neil

From:	DAUBIGNE Sebastien <sebastien.daubigne <at> atos.net>
To:	Neil Swallow/GBR/CSC <at> CSC, Tony Griffiths
            <tony_griffiths <at> symantec.com>
Cc:	"veritas-vx <at> mailman.eng.auburn.edu"
            <veritas-vx <at> mailman.eng.auburn.edu>
Date:	29/11/2012 15:38
Subject:	RE: [Veritas-vx] EMC VMAX with VxVM 5.0

"modinfo |grep vx" would give you the exact revision of VxVM.
MP3 is highly recommended for 5.0 (see
https://sort.symantec.com/checklist/install), latest rev is MP3RP5HF1 for
vxvm module.

Also when you say " I've manually disabled the path and created a separate
vxfs..." : do you mean that you made you filesystem directly on the Solaris
path, for instance /dev/rdsk/c3t50000974081A7118d1s0 ?

Did you disable all paths to the EMC storage in DMP (vxdmpadm -f
disable ...) to prevent VxVM send any I/O to the VMAX during your test ?

if this is the case, you can exclude any VxVM/DMP issue : this could be
Solaris kernel/driver/firmware issue, but under no circumstances VxVM
issue, since no VxVM component was involved in your test.

I assume you ran EMCgrab+HEAT and applied all prereqs (patchs,
firmwares, /etc/system settings :  ssd_io_time, ssd_max_throttle, ...)

Inappropriate queue depth settings can cause transport errors : for
instance, max_throttle recommended setting for DMX is 20 for EMC simples
LUNs, 32 for metaLUNs).

-----Message d'origine-----
De : veritas-vx-bounces <at> mailman.eng.auburn.edu [
mailto:veritas-vx-bounces <at> mailman.eng.auburn.edu] De la part de Neil
Swallow
Envoyé : jeudi 29 novembre 2012 16:03
À : Tony Griffiths
Cc : veritas-vx <at> mailman.eng.auburn.edu
Objet : Re: [Veritas-vx] EMC VMAX with VxVM 5.0

Tony,

plenty of errors in iostat ....

# iostat -En
c2t50060E80004469D0d0 Soft Errors: 0 Hard Errors: 0 Transport Errors: 0
Vendor: HITACHI  Product: DF600F           Revision: 0000 Serial No:
Size: 53.69GB <53687091200 bytes>
Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 0
Illegal Request: 2 Predictive Failure Analysis: 0
c2t50060E80004469D1d0 Soft Errors: 0 Hard Errors: 0 Transport Errors: 0
Vendor: HITACHI  Product: DF600F           Revision: 0000 Serial No:
Size: 53.69GB <53687091200 bytes>
Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 0
Illegal Request: 2 Predictive Failure Analysis: 0
c3t50000974081A7118d1 Soft Errors: 0 Hard Errors: 372 Transport Errors: 383
Vendor: EMC      Product: SYMMETRIX        Revision: 5874 Serial No:
Size: 59.06GB <59061043200 bytes>
Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 0
Illegal Request: 0 Predictive Failure Analysis: 0
c3t50000974081A7118d0 Soft Errors: 0 Hard Errors: 0 Transport Errors: 0
Vendor: EMC      Product: SYMMETRIX        Revision: 5874 Serial No:
Size: 0.00GB <2949120 bytes>
Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 0
Illegal Request: 0 Predictive Failure Analysis: 0

Straight 5.0GA as far as I know - I assume that's what this is telling
me....
PKGINST:  VRTSvxvm
VERSION:  5.0,REV=05.11.2006.17.55

thanks,
Neil

From:   Tony Griffiths <tony_griffiths <at> symantec.com>
To:     "P.Tsvetkov <at> inform.gazprom.ru" <P.Tsvetkov <at> inform.gazprom.ru>,
            Neil Swallow/GBR/CSC <at> CSC, "veritas-vx <at> mailman.eng.auburn.edu"
            <veritas-vx <at> mailman.eng.auburn.edu>
Date:   29/11/2012 13:37
Subject:        RE: [Veritas-vx] EMC VMAX with VxVM 5.0

Hi
Are the errors reported in iostat -En ?
Also is this VxVM 5.0 GA or a later update i.e 5.0MP3, 5.1 ...

cheers
tony

-----Original Message-----
From: veritas-vx-bounces <at> mailman.eng.auburn.edu [
mailto:veritas-vx-bounces <at> mailman.eng.auburn.edu] On Behalf Of
P.Tsvetkov <at> inform.gazprom.ru
Sent: 29 November 2012 13:26
To: nswallow <at> csc.com; veritas-vx <at> mailman.eng.auburn.edu
Subject: Re: [Veritas-vx] EMC VMAX with VxVM 5.0

Hello Neil,

VxVM  gives you no errors if there are no problems in SAN.

SAN can be a problem even if there are seen no critical errors on switches.
Cables , buffer credits , 8Gbps Brocade Fill Word etc.

If hba is ok, if frond-end VMAX port is ok, if cables are ok (and switches)
then VxVM is ok as well

Regards, Pavel

-----Original Message-----
From: veritas-vx-bounces <at> mailman.eng.auburn.edu [
mailto:veritas-vx-bounces <at> mailman.eng.auburn.edu] On Behalf Of Neil Swallow
Sent: Thursday, November 29, 2012 4:54 PM
To: veritas-vx <at> mailman.eng.auburn.edu
Subject: [Veritas-vx] EMC VMAX with VxVM 5.0

Hello all,

Just after some feedback on whether anyone has experienced anything similar
to an issue we're currently seeing.

We're trying to migrate from an HDS SAN to an EMC VMAX on a Solaris 10
server.  We have the server up to supported levels for drivers etc. and
have removed one of two paths to the HDS and routed that to the EMC and all
is seen OK.  However when we try using the EMC (mirroring the volumes from
the HDS to the VMAX) we are inundated with scsi transport errors and a lot
of i/o wait time.  DMP (VX, not powerpath) is disabling the path and
re-enabling it at random points (not necessarily during mirroring) and even
if the mirror completes the plexes on the VMAX LUN are disabling eventually
and vxdisk list reports the LUN as failing.

I've manually disabled the path and created a separate (vxfs) fileystem on
the LUN and done some file copies etc and still get problems so I'm not
convinced it's a DMP issue.   I've also done the same with a UFS filesytem
and oddly UFS provides the least amount of i/o waiting and out-and-out
read/write failures of the copy commands etc. but still registers lots of
transport errors.

With no issues on HDS I'm loathe to blame any of the VX elements but EMC
are providing no help since the VMAX itself and all the switches are
reporting no issues and they are trying to blame vxvm/vxdmp/vxfs.  Whilst I
agree that things appear better without any VX involved, the issues do not
go away entirely so I am currently putting that down to a lower tolerance
to issues on the part of the various VX elements.

Anyway, if anyone has any idea/suggestions/similar issues (any additional
logging I can add at a VX level to help prove anything) that have been
rectified, I'd appreciate it

thanks,
Neil

_______________________________________________
Veritas-vx maillist  -  Veritas-vx <at> mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
_______________________________________________
Veritas-vx maillist  -  Veritas-vx <at> mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx

_______________________________________________
Veritas-vx maillist  -  Veritas-vx <at> mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
________________________________

Ce message et les pièces jointes sont confidentiels et réservés à l'usage
exclusif de ses destinataires. Il peut également être protégé par le secret
professionnel. Si vous recevez ce message par erreur, merci d'en avertir
immédiatement l'expéditeur et de le détruire. L'intégrité du message ne
pouvant être assurée sur Internet, la responsabilité du groupe Atos ne
pourra être engagée quant au contenu de ce message. Bien que les meilleurs
efforts soient faits pour maintenir cette transmission exempte de tout
virus, l'expéditeur ne donne aucune garantie à cet égard et sa
responsabilité ne saurait être engagée pour tout dommage résultant d'un
virus transmis.

This e-mail and the documents attached are confidential and intended solely
for the addressee; it may also be privileged. If you receive this e-mail in
error, please notify the sender immediately and destroy it. As its
integrity cannot be secured on the Internet, the Atos group liability
cannot be triggered for the message content. Although the sender endeavors
to maintain a computer virus-free network, the sender does not warrant that
this transmission is virus-free and will not be liable for any damages
resulting from any virus transmitted.
Permalink | Reply | 1 comment |
headers
Neil Swallow | 29 Nov 2012 13:53
Favicon

EMC VMAX with VxVM 5.0


Hello all,

Just after some feedback on whether anyone has experienced anything similar
to an issue we're currently seeing.

We're trying to migrate from an HDS SAN to an EMC VMAX on a Solaris 10
server.  We have the server up to supported levels for drivers etc. and
have removed one of two paths to the HDS and routed that to the EMC and all
is seen OK.  However when we try using the EMC (mirroring the volumes from
the HDS to the VMAX) we are inundated with scsi transport errors and a lot
of i/o wait time.  DMP (VX, not powerpath) is disabling the path and
re-enabling it at random points (not necessarily during mirroring) and even
if the mirror completes the plexes on the VMAX LUN are disabling eventually
and vxdisk list reports the LUN as failing.

I've manually disabled the path and created a separate (vxfs) fileystem on
the LUN and done some file copies etc and still get problems so I'm not
convinced it's a DMP issue.   I've also done the same with a UFS filesytem
and oddly UFS provides the least amount of i/o waiting and out-and-out
read/write failures of the copy commands etc. but still registers lots of
transport errors.

With no issues on HDS I'm loathe to blame any of the VX elements but EMC
are providing no help since the VMAX itself and all the switches are
reporting no issues and they are trying to blame vxvm/vxdmp/vxfs.  Whilst I
agree that things appear better without any VX involved, the issues do not
go away entirely so I am currently putting that down to a lower tolerance
to issues on the part of the various VX elements.

Anyway, if anyone has any idea/suggestions/similar issues (any additional
logging I can add at a VX level to help prove anything) that have been
rectified, I'd appreciate it

thanks,
Neil
Permalink | Reply | 4 comments |
headers
yiorgos kapellakis | 27 Nov 2012 10:14
Picon

Veritas 6.0 and 5.0

Hello all,
 
I am new in veritas and I want some help.
 
I want to install and train myself in veritas storage and cluster.
 
I search and found from symantec veritas 6.0 but in work we use veritas 5.0
 
Can someone please tell me if they have big differences??
 
If yes from where can I download veritas 5.0??
 
 
Kindest Regards,
George
<div>
<div>Hello all,</div>
<div>&nbsp;</div>
<div>I am new in veritas and I want some help.</div>
<div>&nbsp;</div>
<div>I want to install and train myself in veritas storage and cluster.</div>
<div>&nbsp;</div>
<div>I search and found from symantec veritas 6.0 but in work we use veritas 5.0</div>
<div>&nbsp;</div>
<div>Can someone please tell me if they have big differences??</div>
<div>&nbsp;</div>
<div>If yes from where can I download veritas 5.0??</div>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div>Kindest Regards,</div>
<div>George</div>
</div>
Permalink | Reply | 3 comments |
headers
phil.coleman | 26 Jul 2012 17:56

Re: Question over DMP partitionsize

Hi William,
	Thanks for the reply. Not sure how to get this track cach size?
What's confusing me most here is that the values are so different between
the two arrays. They're identical models set-up up the same and with the
same number of disks allocated to the servers - sorry, forgot to mention
they're in an HA pair using VCS. The only difference is that IBM_SHARK0 is
local to the server where the workload is currently running, and IBM_SHARK1
is in another building about 1.5KM's away. It's this disparity that is
confusing me and making me wonder whether an issue we are seeing is being
caused by this, or if it's an indication of an issue, though I've been
informed by our storage people that there's nothing wrong with either
array.
	This is certainly not something we've changed so I don't know if
VxVM/DMP is throttling things back because it's seeing an issue. I have
seen messages in the /etc/vx/dmpevents.log file for disks in the IBM_SHARK1
array reporting 'Throttled Path' and then 'Un-throttled Path' and I'm
trying to work out if the two are linked.

Cheers
Phil.

                                                                           
             William Havey                                                 
             <bbhavey <at> gmail.co                                             
             m>                                                         To 
                                       phil.coleman <at> ba.com                 
             26/07/2012 15:48                                           cc 

                                                                   Subject 
                                       Re: [Veritas-vx] Question over DMP  
                                       partitionsize                       

Partitionsize is in play when the iopolicy is Balanced, which is the
default policy. You have Balanced.

It is defined as "The partitionsize attribute: Each successive I/O starting
within in this range (default is 2048 sectors) goes through the same path
as the previous I/O"

The man page has "Takes the track cache into consideration when balancing
I/O across paths"

What is the track cache size on each array? Seems that the partitionsize
should be the same value as the track cache size.

On Thu, Jul 26, 2012 at 7:09 AM, <phil.coleman <at> ba.com> wrote:

  Hi,
          I'm trying to understand why one array has a wildly different
  partitionsize value to the other...

  fuj411:/root# vxdmpadm getattr arrayname IBM_SHARK partitionsize
  ENCLR_NAME     DEFAULT        CURRENT
  ============================================
  IBM_SHARK0     2048           2048
  IBM_SHARK1     256            512
  fuj411:/root#

  Both arrays are IBM ESS SHARK 2105's which are active/active and
  operating
  in a Balanced i/o policy...

  fuj411:/root# vxdmpadm getattr arrayname IBM_SHARK iopolicy
  ENCLR_NAME     DEFAULT        CURRENT
  ============================================
  IBM_SHARK0     Balanced       Balanced
  IBM_SHARK1     Balanced       Balanced
  fuj411:/root#

  The server is a Fujitsu PW850 running Solaris 10 with VxVM v4.1 MP2. The
  volume are mirrored between the two arrays.

  I'm trying to get a better understanding of what this means and why it
  would be so different between the two arrays. Any help greatly
  appreciated.

  Cheers
  Phil.

  --
  This message is private and confidential and may also be legally
  privileged.  If you have received this message in error, please email it
  back to the sender and immediately permanently delete it from your
  computer system.  Please do not read, print, re-transmit, store or act in
  reliance on it or any attachments.

  British Airways may monitor email traffic data and also the content of
  emails, where permitted by law, for the purposes of security and staff
  training and in order to prevent or detect unauthorised use of the
  British Airways email system.

  Virus checking of emails (including attachments) is the responsibility of
  the recipient.

  British Airways Plc is a public limited company registered in England and
  Wales.  Registered number: 1777777.  Registered office: Waterside, PO Box
  365, Harmondsworth, West Drayton, Middlesex, England, UB7 0GB.

  Additional terms and conditions are available on our website: www.ba.com

  _______________________________________________
  Veritas-vx maillist  -  Veritas-vx <at> mailman.eng.auburn.edu
  http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx

--
This message is private and confidential and may also be legally privileged.  If you have received this
message in error, please email it back to the sender and immediately permanently delete it from your
computer system.  Please do not read, print, re-transmit, store or act in reliance on it or any attachments.

British Airways may monitor email traffic data and also the content of emails, where permitted by law, for
the purposes of security and staff training and in order to prevent or detect unauthorised use of the
British Airways email system.

Virus checking of emails (including attachments) is the responsibility of the recipient.

British Airways Plc is a public limited company registered in England and Wales.  Registered number:
1777777.  Registered office: Waterside, PO Box 365, Harmondsworth, West Drayton, Middlesex, England,
UB7 0GB.

Additional terms and conditions are available on our website: www.ba.com
Permalink | Reply | 5 comments |
headers
phil.coleman | 26 Jul 2012 13:09

Question over DMP partitionsize


Hi,
	I'm trying to understand why one array has a wildly different
partitionsize value to the other...

fuj411:/root# vxdmpadm getattr arrayname IBM_SHARK partitionsize
ENCLR_NAME     DEFAULT        CURRENT
============================================
IBM_SHARK0     2048           2048
IBM_SHARK1     256            512
fuj411:/root#

Both arrays are IBM ESS SHARK 2105's which are active/active and operating
in a Balanced i/o policy...

fuj411:/root# vxdmpadm getattr arrayname IBM_SHARK iopolicy
ENCLR_NAME     DEFAULT        CURRENT
============================================
IBM_SHARK0     Balanced       Balanced
IBM_SHARK1     Balanced       Balanced
fuj411:/root#

The server is a Fujitsu PW850 running Solaris 10 with VxVM v4.1 MP2. The
volume are mirrored between the two arrays.

I'm trying to get a better understanding of what this means and why it
would be so different between the two arrays. Any help greatly appreciated.

Cheers
Phil.

--
This message is private and confidential and may also be legally privileged.  If you have received this
message in error, please email it back to the sender and immediately permanently delete it from your
computer system.  Please do not read, print, re-transmit, store or act in reliance on it or any attachments.

British Airways may monitor email traffic data and also the content of emails, where permitted by law, for
the purposes of security and staff training and in order to prevent or detect unauthorised use of the
British Airways email system.

Virus checking of emails (including attachments) is the responsibility of the recipient.

British Airways Plc is a public limited company registered in England and Wales.  Registered number:
1777777.  Registered office: Waterside, PO Box 365, Harmondsworth, West Drayton, Middlesex, England,
UB7 0GB.

Additional terms and conditions are available on our website: www.ba.com
Permalink | Reply | 1 comment |

Gmane