<?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: LUN EVA in Disk Enclosures</title>
    <link>https://community.hpe.com/t5/disk-enclosures/lun-eva/m-p/3941093#M22802</link>
    <description>The best thing is to split it, but if you do not wish this, and are thinking of snapshot or snapclone/mirrorclone remeber that if the data is a database table, you will have problems rebuilding it from a snapXXX&lt;BR /&gt;If the LUN has stabile data..do several snaps during the day and inc at night..no problem for us</description>
    <pubDate>Fri, 09 Feb 2007 07:30:45 GMT</pubDate>
    <dc:creator>NDD</dc:creator>
    <dc:date>2007-02-09T07:30:45Z</dc:date>
    <item>
      <title>LUN EVA</title>
      <link>https://community.hpe.com/t5/disk-enclosures/lun-eva/m-p/3941090#M22799</link>
      <description>Hi!!!&lt;BR /&gt;&lt;BR /&gt;The operating system (windows, linux, hpux) supports lun of 2TeraBytes?&lt;BR /&gt;&lt;BR /&gt;greetings&lt;BR /&gt;&lt;BR /&gt;Ale</description>
      <pubDate>Thu, 08 Feb 2007 10:35:04 GMT</pubDate>
      <guid>https://community.hpe.com/t5/disk-enclosures/lun-eva/m-p/3941090#M22799</guid>
      <dc:creator>AleDC</dc:creator>
      <dc:date>2007-02-08T10:35:04Z</dc:date>
    </item>
    <item>
      <title>Re: LUN EVA</title>
      <link>https://community.hpe.com/t5/disk-enclosures/lun-eva/m-p/3941091#M22800</link>
      <description>I know that Windows and HPUX can suport the 2Tb LUN, but I would not recommmend it. My environment has been on an EVA3000 and and EVA8000. Your better off splitting the load of the capacity into say 10x200Gb Luns and if possible over multiple HBA's or HBA ports.  Additionally you may need to run the diskpar utility for Windows as it doesn't format the appropriate number of sectors, thus causing redundant and useless rights to the LUNS everytime you need to right data.  As for Linux I can't speak to.  Hope this helps. &lt;BR /&gt;&lt;BR /&gt;Regards,&lt;BR /&gt;Jose Aguilar-Systems Engineer&lt;BR /&gt;SunGard Availability Services,Inc.</description>
      <pubDate>Thu, 08 Feb 2007 10:48:22 GMT</pubDate>
      <guid>https://community.hpe.com/t5/disk-enclosures/lun-eva/m-p/3941091#M22800</guid>
      <dc:creator>JAguilar</dc:creator>
      <dc:date>2007-02-08T10:48:22Z</dc:date>
    </item>
    <item>
      <title>Re: LUN EVA</title>
      <link>https://community.hpe.com/t5/disk-enclosures/lun-eva/m-p/3941092#M22801</link>
      <description>The ext3 file system (linux native) can support  file systems of 32 TiB.&lt;BR /&gt;&lt;BR /&gt;Anyway, how do you handle 2 TB of backup in a single LUN? And the restore?&lt;BR /&gt;&lt;BR /&gt;Consider split the LUN in smaller parts.</description>
      <pubDate>Thu, 08 Feb 2007 10:56:06 GMT</pubDate>
      <guid>https://community.hpe.com/t5/disk-enclosures/lun-eva/m-p/3941092#M22801</guid>
      <dc:creator>Ivan Ferreira</dc:creator>
      <dc:date>2007-02-08T10:56:06Z</dc:date>
    </item>
    <item>
      <title>Re: LUN EVA</title>
      <link>https://community.hpe.com/t5/disk-enclosures/lun-eva/m-p/3941093#M22802</link>
      <description>The best thing is to split it, but if you do not wish this, and are thinking of snapshot or snapclone/mirrorclone remeber that if the data is a database table, you will have problems rebuilding it from a snapXXX&lt;BR /&gt;If the LUN has stabile data..do several snaps during the day and inc at night..no problem for us</description>
      <pubDate>Fri, 09 Feb 2007 07:30:45 GMT</pubDate>
      <guid>https://community.hpe.com/t5/disk-enclosures/lun-eva/m-p/3941093#M22802</guid>
      <dc:creator>NDD</dc:creator>
      <dc:date>2007-02-09T07:30:45Z</dc:date>
    </item>
    <item>
      <title>Re: LUN EVA</title>
      <link>https://community.hpe.com/t5/disk-enclosures/lun-eva/m-p/3941094#M22803</link>
      <description>Windows 2003 SP1 introduced support for LUNs &amp;gt;2TB.&lt;BR /&gt;&lt;BR /&gt;See the following article for the details.&lt;BR /&gt;&lt;A href="http://www.microsoft.com/whdc/device/storage/LUN_SP1.mspx" target="_blank"&gt;http://www.microsoft.com/whdc/device/storage/LUN_SP1.mspx&lt;/A&gt; &lt;BR /&gt;&lt;BR /&gt;However, handling large LUNs can make life difficult (fsck, backup, restore etc.)&lt;BR /&gt;&lt;BR /&gt;And, the EVA currently "only" supports LUNs up to 2TB. Stay tuned for a change ...&lt;BR /&gt;&lt;BR /&gt;Cheers&lt;BR /&gt;Peter</description>
      <pubDate>Fri, 09 Feb 2007 15:23:19 GMT</pubDate>
      <guid>https://community.hpe.com/t5/disk-enclosures/lun-eva/m-p/3941094#M22803</guid>
      <dc:creator>Peter Mattei</dc:creator>
      <dc:date>2007-02-09T15:23:19Z</dc:date>
    </item>
    <item>
      <title>Re: LUN EVA</title>
      <link>https://community.hpe.com/t5/disk-enclosures/lun-eva/m-p/3941095#M22804</link>
      <description>One more problem I can think is with the Scsi queue Depth. The default queue depth is only 8 which can be little too short for a lun of size 2 TB. &lt;BR /&gt;&lt;BR /&gt;Ofcourse, you can increase the queue depth if you indeed decided to go with 2 TB.</description>
      <pubDate>Tue, 13 Feb 2007 13:22:26 GMT</pubDate>
      <guid>https://community.hpe.com/t5/disk-enclosures/lun-eva/m-p/3941095#M22804</guid>
      <dc:creator>Sundar_7</dc:creator>
      <dc:date>2007-02-13T13:22:26Z</dc:date>
    </item>
    <item>
      <title>Re: LUN EVA</title>
      <link>https://community.hpe.com/t5/disk-enclosures/lun-eva/m-p/3941096#M22805</link>
      <description>Sorry, I forgot to mention that the above post on the queue depth is only applicable to HP-UX hosts.</description>
      <pubDate>Tue, 13 Feb 2007 13:23:28 GMT</pubDate>
      <guid>https://community.hpe.com/t5/disk-enclosures/lun-eva/m-p/3941096#M22805</guid>
      <dc:creator>Sundar_7</dc:creator>
      <dc:date>2007-02-13T13:23:28Z</dc:date>
    </item>
  </channel>
</rss>

