<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: /dev/cdisk/disk? in Operating System - HP-UX</title>
    <link>https://community.hpe.com/t5/operating-system-hp-ux/dev-cdisk-disk/m-p/4755094#M388587</link>
    <description>Hey;&lt;BR /&gt;&lt;BR /&gt;Thanks for the info.  Looks like I got a bit more reading to do.  &lt;BR /&gt;&lt;BR /&gt;Out of curiosity, why is there a need for cluster dsfs?  You vgexport -s, vgimport -s, why does it matter if /dev/disk/disk32 on one node is /dev/disk/disk28 on another?&lt;BR /&gt;&lt;BR /&gt;Seems this is more of a solution looking for a problem... so I must be missing something.&lt;BR /&gt;&lt;BR /&gt;Thanks again for the replies.&lt;BR /&gt;&lt;BR /&gt;Doug O'Leary</description>
    <pubDate>Sat, 19 Feb 2011 17:20:41 GMT</pubDate>
    <dc:creator>Doug O'Leary</dc:creator>
    <dc:date>2011-02-19T17:20:41Z</dc:date>
    <item>
      <title>/dev/cdisk/disk?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/dev-cdisk-disk/m-p/4755089#M388582</link>
      <description>Hey;&lt;BR /&gt;&lt;BR /&gt;I'll be helping a cohort build a new cluster on a couple of HPUX 11.31 systems on monday - at the moment, since it's very late on a Friday, that's about all I know of the systems.&lt;BR /&gt;&lt;BR /&gt;He was asking about some differences in the ioscans between the two systems in that one of them is showing /dev/cdisk/disk## along with most of the legacy devices..&lt;BR /&gt;&lt;BR /&gt;What's a cdisk?  I know what the legacy devices are and I know what the persistent ones are, but I've not seen a cdisk before...&lt;BR /&gt;&lt;BR /&gt;Any hints greatly appreciated.&lt;BR /&gt;&lt;BR /&gt;Doug O'Leary</description>
      <pubDate>Fri, 18 Feb 2011 23:21:57 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/dev-cdisk-disk/m-p/4755089#M388582</guid>
      <dc:creator>Doug O'Leary</dc:creator>
      <dc:date>2011-02-18T23:21:57Z</dc:date>
    </item>
    <item>
      <title>Re: /dev/cdisk/disk?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/dev-cdisk-disk/m-p/4755090#M388583</link>
      <description>Cluster-wide Device Special Files (cDSFs)&lt;BR /&gt;&lt;BR /&gt;Because DSF names may be duplicated between one host and other, it is possible fordifferent storage devices to have the same name on different nodes in a cluster, and for the same piece of storage to be addressed by different names. Cluster-wide device files (cDSFs), available as of the September 2010 HP-UX Fusion Release, ensure that each storage device used by the cluster has a unique device file name.&lt;BR /&gt;Please refer the following article for complete information,&lt;BR /&gt;&lt;A href="http://www.hpuxtips.es/?q=node/263" target="_blank"&gt;http://www.hpuxtips.es/?q=node/263&lt;/A&gt;&lt;BR /&gt;</description>
      <pubDate>Sat, 19 Feb 2011 04:59:37 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/dev-cdisk-disk/m-p/4755090#M388583</guid>
      <dc:creator>nijokj</dc:creator>
      <dc:date>2011-02-19T04:59:37Z</dc:date>
    </item>
    <item>
      <title>Re: /dev/cdisk/disk?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/dev-cdisk-disk/m-p/4755091#M388584</link>
      <description>hi,&lt;BR /&gt;&lt;BR /&gt;It is cluster device special files (cDSFs). This feature is effective only in a cluster environment and requires that you install HP Serviceguard A.11.20 and patch it to support cluster-wide device special files.&lt;BR /&gt;&lt;BR /&gt;Cluster device special files (cDSFs) require the installation of the following patches on HP-UX 11iv3 September 2010 OE:&lt;BR /&gt;1. PHSS_41225 11.31 Serviceguard A.11.20.00 patch&lt;BR /&gt;2. PHCO_41235 11.31 iocdsfd(1M) and io_cdsf_config(1M) patch&lt;BR /&gt;&lt;BR /&gt;Rgds...</description>
      <pubDate>Sat, 19 Feb 2011 06:33:19 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/dev-cdisk-disk/m-p/4755091#M388584</guid>
      <dc:creator>P Arumugavel</dc:creator>
      <dc:date>2011-02-19T06:33:19Z</dc:date>
    </item>
    <item>
      <title>Re: /dev/cdisk/disk?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/dev-cdisk-disk/m-p/4755092#M388585</link>
      <description>It`s a new feature i saw in MCSG 11.20&lt;BR /&gt;&lt;BR /&gt;Cluster-wide device special files (cDSFs) are persistent device special files applied&lt;BR /&gt;across a set of nodes. That is, they ensure that the same piece of storage has the same&lt;BR /&gt;devicefile name on all of the nodes that share it; no matter how many paths there are&lt;BR /&gt;to the device, the same cluster DSF is used to address it. If the device is moved, the&lt;BR /&gt;same cDSF still addresses it.&lt;BR /&gt;&lt;BR /&gt;Create the cDSFs.&lt;BR /&gt;&lt;BR /&gt;NOTE: cDSFs apply only to shared storage; &lt;BR /&gt;â ¢ If the cluster does not exist yet, specify the name of each prospective node,&lt;BR /&gt;for example:&lt;BR /&gt;cmsetdsfgroup -n node1 -n node2 -n node3 -n node4&lt;BR /&gt;â ¢ If the cluster does exist, you can simply run:&lt;BR /&gt;cmsetdsfgroup -c&lt;BR /&gt;&lt;BR /&gt;Do read release notes for MCSG 11.20 edition&lt;BR /&gt;for details &amp;amp; implementations&lt;BR /&gt;&lt;BR /&gt;Thanks&lt;BR /&gt;Manix</description>
      <pubDate>Sat, 19 Feb 2011 06:35:23 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/dev-cdisk-disk/m-p/4755092#M388585</guid>
      <dc:creator>Manix</dc:creator>
      <dc:date>2011-02-19T06:35:23Z</dc:date>
    </item>
    <item>
      <title>Re: /dev/cdisk/disk?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/dev-cdisk-disk/m-p/4755093#M388586</link>
      <description>Hi doug,&lt;BR /&gt;&lt;BR /&gt;As mentioned by others it's a cluster wide device file which means that the DSF will be consistent accross the nodes of the cluster as on a local system  the device file is assigned by the kernel of "that node" and when a vgimport on the other node is done, the same disk would have a  different DSF as it is assigned by the kernel on the other node.&lt;BR /&gt;&lt;BR /&gt;To remove this feature of "asymmetry" of the classic  "persistent" DSF, a DSF that "persists" accross reboots but normally did not "persist" accross the nodes of the cluster came the concept of the cDSF in the releases mentioned by the other forumers. The commands cmsetdsfgroup and io_cdsf_config are related to the cDSFs.&lt;BR /&gt;&lt;BR /&gt;Regards&lt;BR /&gt;Ismail Azad</description>
      <pubDate>Sat, 19 Feb 2011 08:09:40 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/dev-cdisk-disk/m-p/4755093#M388586</guid>
      <dc:creator>Ismail Azad</dc:creator>
      <dc:date>2011-02-19T08:09:40Z</dc:date>
    </item>
    <item>
      <title>Re: /dev/cdisk/disk?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/dev-cdisk-disk/m-p/4755094#M388587</link>
      <description>Hey;&lt;BR /&gt;&lt;BR /&gt;Thanks for the info.  Looks like I got a bit more reading to do.  &lt;BR /&gt;&lt;BR /&gt;Out of curiosity, why is there a need for cluster dsfs?  You vgexport -s, vgimport -s, why does it matter if /dev/disk/disk32 on one node is /dev/disk/disk28 on another?&lt;BR /&gt;&lt;BR /&gt;Seems this is more of a solution looking for a problem... so I must be missing something.&lt;BR /&gt;&lt;BR /&gt;Thanks again for the replies.&lt;BR /&gt;&lt;BR /&gt;Doug O'Leary</description>
      <pubDate>Sat, 19 Feb 2011 17:20:41 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/dev-cdisk-disk/m-p/4755094#M388587</guid>
      <dc:creator>Doug O'Leary</dc:creator>
      <dc:date>2011-02-19T17:20:41Z</dc:date>
    </item>
    <item>
      <title>Re: /dev/cdisk/disk?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/dev-cdisk-disk/m-p/4755095#M388588</link>
      <description>Because DSF names may be duplicated between one host and other, it is possible for&lt;BR /&gt;different storage devices to have the same name on different nodes in a cluster, and&lt;BR /&gt;for the same piece of storage to be addressed by different names. Cluster-wide device files (cDSFs), available as of the September 2010 HP-UX Fusion Release, ensure thateach storage device used by the cluster has a unique device file name.&lt;BR /&gt;&lt;BR /&gt;HP recommends that you use cDSFs for the storage devices in the cluster because this&lt;BR /&gt;makes it simpler to deploy and maintain a cluster, and removes a potential source of&lt;BR /&gt;configuration errors. &lt;BR /&gt;&lt;BR /&gt;Hope this helps.&lt;BR /&gt;&lt;BR /&gt;Thanks&lt;BR /&gt;Manix</description>
      <pubDate>Sat, 19 Feb 2011 17:38:17 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/dev-cdisk-disk/m-p/4755095#M388588</guid>
      <dc:creator>Manix</dc:creator>
      <dc:date>2011-02-19T17:38:17Z</dc:date>
    </item>
    <item>
      <title>Re: /dev/cdisk/disk?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/dev-cdisk-disk/m-p/4755096#M388589</link>
      <description>Hi Doug,&lt;BR /&gt;&lt;BR /&gt;&amp;gt; You vgexport -s, vgimport -s, why does it matter if /dev/disk/disk32 on one node is /dev/disk/disk28 on another?&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;There are times when I have configured a cluster on a "test server" and run into problems like... let's take the example you mentioned a /dev/disk/disk32 and /dev/disk/disk28 being the same disk on different nodes of the cluster. Let's say I am creating vg01 as a "shared volume group" and have chosen /dev/disk/disk32 as my P.V and the /dev/dsk/c2t3d0 happens to be the mirror of the boot disk on the other node!. Didn't get it right... That /dev/dsk/c2t3d0 very well could be your /dev/disk/disk32  . Now you've run into a problem. Ofcourse there are "best practises" to follow but as Manix rightly mentioned about cDSFs the key point being..&lt;BR /&gt;&lt;BR /&gt;&amp;gt; and removes a potential source of&lt;BR /&gt;configuration errors.&lt;BR /&gt;&lt;BR /&gt;Regards&lt;BR /&gt;Ismail Azad&lt;BR /&gt;</description>
      <pubDate>Sat, 19 Feb 2011 18:08:10 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/dev-cdisk-disk/m-p/4755096#M388589</guid>
      <dc:creator>Ismail Azad</dc:creator>
      <dc:date>2011-02-19T18:08:10Z</dc:date>
    </item>
    <item>
      <title>Re: /dev/cdisk/disk?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/dev-cdisk-disk/m-p/4755097#M388590</link>
      <description>Hey;&lt;BR /&gt;&lt;BR /&gt;I'm still not really seeing the problem; however, that doesn't mean there's not one there.&lt;BR /&gt;&lt;BR /&gt;If I create /dev/vg01 with /dev/disk/disk32, export it with "vgexport -s ... " and "vgimport -s ..." it's going to grab that one disk regardless of the name on the second host because it's looking for the matching vgid in the descriptor area.  I don't really care if the disk on the second node is /dev/disk/disk32, disk23, or even a legacy device.  &lt;BR /&gt;&lt;BR /&gt;Consistency's a good thing, don't get me wrong; I'm just not seeing the problem this is supposed to address.&lt;BR /&gt;&lt;BR /&gt;I can see this coming in handy when you're trying to make sure a specific lun is either used or not used.  I have scripts that parse out xpinfo (hds), inq (emc) and evainfo to identify which specifc lun matches which legacy and persistent device.  Maybe that's why I'm not seeing the problem; I've already worked my way around it...&lt;BR /&gt;&lt;BR /&gt;And, btw, the link that nijokj provided is excellent.  When I had my first conversation with my cohort, he was saying that his directions told him to run csshsetup, cmsetdfsgroup, etc, which confused me greatly.  At least now I know why he's running those commands.  &lt;BR /&gt;&lt;BR /&gt;Thanks again for the replies.&lt;BR /&gt;&lt;BR /&gt;Doug O'Leary</description>
      <pubDate>Sat, 19 Feb 2011 18:34:46 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/dev-cdisk-disk/m-p/4755097#M388590</guid>
      <dc:creator>Doug O'Leary</dc:creator>
      <dc:date>2011-02-19T18:34:46Z</dc:date>
    </item>
    <item>
      <title>Re: /dev/cdisk/disk?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/dev-cdisk-disk/m-p/4755098#M388591</link>
      <description>Hello Dough,&lt;BR /&gt;&lt;BR /&gt;What you said is correct that 'vgimport -s 'will always bring the right diks into a VG pool besause it don`t even reading device files. It`s reading VGID metadata on the diks.&lt;BR /&gt;&lt;BR /&gt;But just think about persistent device files&lt;BR /&gt;on 11.31 where the device files names can be&lt;BR /&gt;kept same even after the HW replacements &amp;amp; change in lun paths, in that regard if we have the same devices with the exact similar names across the nodes then maintenance would be easy , example to check if the same lun is visible from all the nodes at the same time you may need to run complex commands to get PVID /VGID ,what if the device files tells you that , make sense on 11.31 .&lt;BR /&gt;&lt;BR /&gt;Other wise vgimport -s &amp;amp; xd command with PVID/VGID is good enough to do things.&lt;BR /&gt;&lt;BR /&gt;Don`t you think it makes the job easy ??&lt;BR /&gt;&lt;BR /&gt;Thanks&lt;BR /&gt;Manix</description>
      <pubDate>Sat, 19 Feb 2011 18:47:14 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/dev-cdisk-disk/m-p/4755098#M388591</guid>
      <dc:creator>Manix</dc:creator>
      <dc:date>2011-02-19T18:47:14Z</dc:date>
    </item>
    <item>
      <title>Re: /dev/cdisk/disk?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/dev-cdisk-disk/m-p/4755099#M388592</link>
      <description>Hi,&lt;BR /&gt;&lt;BR /&gt;&amp;gt; I have scripts that parse out xpinfo (hds), inq (emc) and evainfo to identify which specifc lun matches which legacy and persistent device. Maybe that's why I'm not seeing the problem; I've already worked my way around it...&lt;BR /&gt;&lt;BR /&gt;YES... that's why u don't see the difficulty for anyone who would face it. :).&lt;BR /&gt;&lt;BR /&gt;That was "your solution" and I am sure many people have "worked their way around this".. The same purpose that was served by your scripts is now a "feature" of the latest serviceguard.&lt;BR /&gt;&lt;BR /&gt;Regards&lt;BR /&gt;Ismail Azad</description>
      <pubDate>Sat, 19 Feb 2011 18:56:28 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/dev-cdisk-disk/m-p/4755099#M388592</guid>
      <dc:creator>Ismail Azad</dc:creator>
      <dc:date>2011-02-19T18:56:28Z</dc:date>
    </item>
    <item>
      <title>Re: /dev/cdisk/disk?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/dev-cdisk-disk/m-p/4755100#M388593</link>
      <description>Thanks correct !! Ismail.&lt;BR /&gt;&lt;BR /&gt;btw Dough looks you have a bunch of good scripts , do share with us if possible -)&lt;BR /&gt;&lt;BR /&gt;Thanks&lt;BR /&gt;Manix</description>
      <pubDate>Sat, 19 Feb 2011 19:32:01 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/dev-cdisk-disk/m-p/4755100#M388593</guid>
      <dc:creator>Manix</dc:creator>
      <dc:date>2011-02-19T19:32:01Z</dc:date>
    </item>
  </channel>
</rss>

