<?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: Why does L&amp;amp;TT disable write-verify and write cache. in Optical Jukeboxes and Drives</title>
    <link>https://community.hpe.com/t5/optical-jukeboxes-and-drives/why-does-l-amp-tt-disable-write-verify-and-write-cache/m-p/251950#M1915</link>
    <description>&amp;gt;&amp;gt;&amp;gt;If LTT reads the rear panel setting for standalone 5200ex/9100mx for example, then why does it report "disabled" even though the drive (5200ex, 9100mx) is set to position 3 (write-verify enabled)? &lt;BR /&gt;
&lt;BR /&gt;
This could be because you are not power cycling the drive after changing the switch setting.  Also, if you run the Restore Factory Settings test and there are any other settings that need adjusted, then part of the reset procedure is to set write-verify to disabled so that it may be re-enabled using the switch settings.  Again, the drive must then be power cycled, then running device analysis should show that the settings are now correct.  Please try this and let me know how it goes.&lt;BR /&gt;
&lt;BR /&gt;
LTT does support the 1300T for some functions, but not the Restore Factory Settings test.  For example, device analysis is supported for the 1300T.&lt;BR /&gt;
&lt;BR /&gt;
You bring up an excellent point about the 2600T factory settings.  For the 2600T, the factory default is actually to disable the write-verify function, so I am now considering how best to deal with this situation for the Restore Factory Settings test, since enabling write-verify should probably be encouraged.  There is a performance tradeoff; perhaps for 4x the user should be asked to decide whether to have write-verify enabled or disabled as part of the Restore Factory Settings test.</description>
    <pubDate>Tue, 12 Aug 2003 20:40:09 GMT</pubDate>
    <dc:creator>CA877192</dc:creator>
    <dc:date>2003-08-12T20:40:09Z</dc:date>
    <item>
      <title>Why does L&amp;TT disable write-verify and write cache.</title>
      <link>https://community.hpe.com/t5/optical-jukeboxes-and-drives/why-does-l-amp-tt-disable-write-verify-and-write-cache/m-p/251945#M1910</link>
      <description>H/W &amp;amp; S/W platform details:&lt;BR /&gt;
- Compaq ML370 server Win2K/SP3, NTFS RAID5&lt;BR /&gt;
- 220mx jukebox (or 9100mx, 5200ex standalones)&lt;BR /&gt;
- optical devices use separate on-board SCSI&lt;BR /&gt;
- L&amp;amp;TT version 3.1 SR2 (miniport I/O-mode)&lt;BR /&gt;
&lt;BR /&gt;
Standalone drive rear switch in position "3" (direct access and write verify enabled).  We use direct access because our R&amp;amp;D group spec'd it that way specifically - not sure why).&lt;BR /&gt;
&lt;BR /&gt;
Problem a) Restore factory defaults with L&amp;amp;TT and support ticket reports write verify "disabled", with instruction to enable with rear switch (already is).  Server reboot resets to enabled, shown in support ticket.  Why is it doing this?  And isn't factory default write verify "enabled"?&lt;BR /&gt;
&lt;BR /&gt;
Strange thing: When you restore factory defaults with L&amp;amp;TT it does a compare with existing settings and factory defaults.  There is a choice to proceed to reset to defaults or not.  If you elect not to do it, the L&amp;amp;TT still disables the write verify, just as if you chose to reset to defaults.  Bug?&lt;BR /&gt;
&lt;BR /&gt;
Problem b) Boot up our application, access optical device and shutdown application.  Support ticket shows write cache "disabled".  Restoring factory defaults with L&amp;amp;TT or server reboot resets to write cache "enabled".  Any idea why it is being disabled?</description>
      <pubDate>Sun, 10 Aug 2003 03:13:12 GMT</pubDate>
      <guid>https://community.hpe.com/t5/optical-jukeboxes-and-drives/why-does-l-amp-tt-disable-write-verify-and-write-cache/m-p/251945#M1910</guid>
      <dc:creator>noka</dc:creator>
      <dc:date>2003-08-10T03:13:12Z</dc:date>
    </item>
    <item>
      <title>Re: Why does L&amp;TT disable write-verify and write cache.</title>
      <link>https://community.hpe.com/t5/optical-jukeboxes-and-drives/why-does-l-amp-tt-disable-write-verify-and-write-cache/m-p/251946#M1911</link>
      <description>For our MO drives, the write with verify function is determined as the ORed condition of the mode page setting ("Force Verify" bit - set via SCSI) and the rear-switch setting (standalone) / front-panel setting (libraries).  Since we wanted the user to have the ability to change the write with verify setting via the standalone rear-switch or the library front panel, this means that the Force Verify setting (which is what LTT is controlling) must be disabled.  This occurs when the user elects to set the configuration settings to factory default within the "Restore Factory Defaults" test, then we output a message asking the user to power cycle the drive and run device analysis to check these settings.  The new settings don't take effect until after the power cycle.  &lt;BR /&gt;
&lt;BR /&gt;
Regarding the setting for write cache, the default configuration for MO is write-cache enabled.  It sounded like from your description that write caching was getting disabled within your application, but not getting re-enabled prior to leaving the application.  If you agree with this, then it would seem that this is an issue for the application, rather than LTT.  Please let me know if you agree.  &lt;BR /&gt;
&lt;BR /&gt;
Regarding the problem with LTT disabling write verify, even though the user selects to not reset to defaults, I agree this is a bug and am now testing a fix for this.  The corrected script will be available in the next week or so via the LTT function "Get Files From Web".  Thank you for spotting this problem.&lt;BR /&gt;
&lt;BR /&gt;
&lt;BR /&gt;</description>
      <pubDate>Mon, 11 Aug 2003 20:23:31 GMT</pubDate>
      <guid>https://community.hpe.com/t5/optical-jukeboxes-and-drives/why-does-l-amp-tt-disable-write-verify-and-write-cache/m-p/251946#M1911</guid>
      <dc:creator>CA877192</dc:creator>
      <dc:date>2003-08-11T20:23:31Z</dc:date>
    </item>
    <item>
      <title>Re: Why does L&amp;TT disable write-verify and write cache.</title>
      <link>https://community.hpe.com/t5/optical-jukeboxes-and-drives/why-does-l-amp-tt-disable-write-verify-and-write-cache/m-p/251947#M1912</link>
      <description>(Sorry long) - OK, if I understand correctly,&lt;BR /&gt;
 &lt;BR /&gt;
Force Verify bit "ORed with" Front/Rear Panel switch = Write with Verify Function enabled&lt;BR /&gt;
&lt;BR /&gt;
If L&amp;amp;TT is controlling the Force Verify bit, which is only one input to the OR, then can I assume that is what's being reported as enabled/disabled in the support ticket?  In other words, if I reset to factory defaults, which clears the Force Verify bit, and also have the rear panel switch set to Write Verify, then when the support ticket reports Write Verify as disabled, it is not really reporting the complete Write with Verify function being disabled, but only one input to the OR being disabled, namely the Force Verify bit?  And can I assume that no matter what the support ticket says, that the rear panel switch (the other input to the OR) will override to sure the Write with Verify function is enabled?  If so, I find the support ticket result to be misleading in telling me Write with Verify is disabled, when the rear panel switch setting is really enabling it.&lt;BR /&gt;
&lt;BR /&gt;
If the above conjecture is true so far, then it might not be such an issue for the 5200ex and 9100mx that both have rear panel switch settings to enable write with verify (which would override L&amp;amp;TT if it clears the Force Verify bit).  But what about e.g. older 1300t or 2600fx MO drives that don't have such a rear panel switch setting.  Can I assume in these cases the Write with Verify function is not an ORed condition but, rather, a reflection of how the Force Verify bit is set via SCSI commands?  And if so, does that mean a restore to factory defaults would really disable the complete Write with Verify function?  And if so, how would a user of L&amp;amp;TT be able to enable Write with Verify again on these older drives?&lt;BR /&gt;
&lt;BR /&gt;
I will need to check on the write cache situation with our application.  I anticipated your response on that after I posted it.&lt;BR /&gt;</description>
      <pubDate>Tue, 12 Aug 2003 02:13:09 GMT</pubDate>
      <guid>https://community.hpe.com/t5/optical-jukeboxes-and-drives/why-does-l-amp-tt-disable-write-verify-and-write-cache/m-p/251947#M1912</guid>
      <dc:creator>noka</dc:creator>
      <dc:date>2003-08-12T02:13:09Z</dc:date>
    </item>
    <item>
      <title>Re: Why does L&amp;TT disable write-verify and write cache.</title>
      <link>https://community.hpe.com/t5/optical-jukeboxes-and-drives/why-does-l-amp-tt-disable-write-verify-and-write-cache/m-p/251948#M1913</link>
      <description>LTT reads the state of Force Verify as the ORed condition of the 2 inputs (mode page and either rear panel setting (standalone) or front panel setting (drive in a library)), but LTT can only change the setting of one of the 2 inputs (the mode page setting).  Please let me know if this clarifies your question.&lt;BR /&gt;
&lt;BR /&gt;
Your assumption is correct that for older MO drives (1300T, 2600T), since there is no panel setting for Force Verify, that in this case the mode page setting is the only way to change Force Verify.  It should be noted that the Restore Factory Settings test is not supported for the 1300T.  Do you think there is a significant need for supporting the 1300T with the Restore Factory Settings test?&lt;BR /&gt;
&lt;BR /&gt;</description>
      <pubDate>Tue, 12 Aug 2003 16:26:30 GMT</pubDate>
      <guid>https://community.hpe.com/t5/optical-jukeboxes-and-drives/why-does-l-amp-tt-disable-write-verify-and-write-cache/m-p/251948#M1913</guid>
      <dc:creator>CA877192</dc:creator>
      <dc:date>2003-08-12T16:26:30Z</dc:date>
    </item>
    <item>
      <title>Re: Why does L&amp;TT disable write-verify and write cache.</title>
      <link>https://community.hpe.com/t5/optical-jukeboxes-and-drives/why-does-l-amp-tt-disable-write-verify-and-write-cache/m-p/251949#M1914</link>
      <description>This type of communication is difficult.  Too bad we can't speak.  It would be much faster, I think.  Let me try to bring it to a conclusion, soon I hope.&lt;BR /&gt;
;-)&lt;BR /&gt;
&lt;BR /&gt;
If LTT reads the rear panel setting for standalone 5200ex/9100mx for example, then why does it report "disabled" even though the drive (5200ex, 9100mx) is set to position 3 (write-verify enabled)?  That's not clear to me.&lt;BR /&gt;
&lt;BR /&gt;
1300t; not much need to support.  We won't support this h/w beyond end of this year anyway.  But does L&amp;amp;TT support the 1300t?  I think HP web says, yes.  If a function can't be done, I assume/hope it is either greyed out or a suitable warning is given.  I don't see any firmware bundles for this drive anyway.  &lt;BR /&gt;
&lt;BR /&gt;
2600fx; is the Force Verify bit (and therefore resultant write verify function) enabled or disabled by factory default?  How would 'restore factory defaults' leave it?</description>
      <pubDate>Tue, 12 Aug 2003 19:55:04 GMT</pubDate>
      <guid>https://community.hpe.com/t5/optical-jukeboxes-and-drives/why-does-l-amp-tt-disable-write-verify-and-write-cache/m-p/251949#M1914</guid>
      <dc:creator>noka</dc:creator>
      <dc:date>2003-08-12T19:55:04Z</dc:date>
    </item>
    <item>
      <title>Re: Why does L&amp;TT disable write-verify and write cache.</title>
      <link>https://community.hpe.com/t5/optical-jukeboxes-and-drives/why-does-l-amp-tt-disable-write-verify-and-write-cache/m-p/251950#M1915</link>
      <description>&amp;gt;&amp;gt;&amp;gt;If LTT reads the rear panel setting for standalone 5200ex/9100mx for example, then why does it report "disabled" even though the drive (5200ex, 9100mx) is set to position 3 (write-verify enabled)? &lt;BR /&gt;
&lt;BR /&gt;
This could be because you are not power cycling the drive after changing the switch setting.  Also, if you run the Restore Factory Settings test and there are any other settings that need adjusted, then part of the reset procedure is to set write-verify to disabled so that it may be re-enabled using the switch settings.  Again, the drive must then be power cycled, then running device analysis should show that the settings are now correct.  Please try this and let me know how it goes.&lt;BR /&gt;
&lt;BR /&gt;
LTT does support the 1300T for some functions, but not the Restore Factory Settings test.  For example, device analysis is supported for the 1300T.&lt;BR /&gt;
&lt;BR /&gt;
You bring up an excellent point about the 2600T factory settings.  For the 2600T, the factory default is actually to disable the write-verify function, so I am now considering how best to deal with this situation for the Restore Factory Settings test, since enabling write-verify should probably be encouraged.  There is a performance tradeoff; perhaps for 4x the user should be asked to decide whether to have write-verify enabled or disabled as part of the Restore Factory Settings test.</description>
      <pubDate>Tue, 12 Aug 2003 20:40:09 GMT</pubDate>
      <guid>https://community.hpe.com/t5/optical-jukeboxes-and-drives/why-does-l-amp-tt-disable-write-verify-and-write-cache/m-p/251950#M1915</guid>
      <dc:creator>CA877192</dc:creator>
      <dc:date>2003-08-12T20:40:09Z</dc:date>
    </item>
    <item>
      <title>Re: Why does L&amp;TT disable write-verify and write cache.</title>
      <link>https://community.hpe.com/t5/optical-jukeboxes-and-drives/why-does-l-amp-tt-disable-write-verify-and-write-cache/m-p/251951#M1916</link>
      <description>&amp;gt;&amp;gt;&amp;gt; "This could be because you are not power cycling the drive after changing the switch setting."&lt;BR /&gt;
&lt;BR /&gt;
Perhaps I was not clear about our rear panel switch setting.  The switch is "always" in position 3, never changed.  So what you are saying is that after restore factory defaults, write-verify is disabled regardless of switch position and that although L&amp;amp;TT may be able to read the switch setting, it won't report "enabled" until the device is power cycled.  If so, I guess I will have to accept that.  But you just said that part of the reset procedure is to disable it.  So the thing that worries me is that someone restarting the application, without power cycling the drive, may assume write-verify is enabled because the switch is in position 3 and always has been!  Comment?&lt;BR /&gt;
 &lt;BR /&gt;
&amp;gt;&amp;gt;&amp;gt; "For the 2600T, the factory default is actually to disable the write-verify function, ..."&lt;BR /&gt;
&lt;BR /&gt;
This is ineresting.  I will have to check with our R&amp;amp;D, but I would guess that our application sets the force verify bit when we start it.  Probably for the 1300t too, come to think of it.  In fact, we probably do it for all the devices I mentioned so far, but I will have to ummm, "verify" that assumption.&lt;BR /&gt;
:-)&lt;BR /&gt;
&lt;BR /&gt;
OK, so 2600fx factory default (and maybe 1300t also) is write-verify "disabled".  What about 5200ex,9100mx,220mx.  I think I read somewhere that factory default for at least one of these devices is "enabled".  If so, I assume the force verify bit is set at the factory (for either new device, or exchange assembly from HP parts center).  Can you confirm?</description>
      <pubDate>Tue, 12 Aug 2003 21:44:25 GMT</pubDate>
      <guid>https://community.hpe.com/t5/optical-jukeboxes-and-drives/why-does-l-amp-tt-disable-write-verify-and-write-cache/m-p/251951#M1916</guid>
      <dc:creator>noka</dc:creator>
      <dc:date>2003-08-12T21:44:25Z</dc:date>
    </item>
    <item>
      <title>Re: Why does L&amp;TT disable write-verify and write cache.</title>
      <link>https://community.hpe.com/t5/optical-jukeboxes-and-drives/why-does-l-amp-tt-disable-write-verify-and-write-cache/m-p/251952#M1917</link>
      <description>I replied to this a week ago, but I just noticed that the reply doesn't show up so I'll try again.&lt;BR /&gt;
&lt;BR /&gt;
Since you aren't changing the switch setting, then it looks like what is happening is that the mode page that includes write-verify is reset to defaults because there is a non-standard setting detected (direct-access is on the same mode page).  This disables write-verify (so that it may be re-enabled using the switch settings).  I think this scenario is confusing because direct-access and write-verify are on the same mode page.  The key is to do the power cycle.  &lt;BR /&gt;
&lt;BR /&gt;
The default for 8X (e suffix, such as 5200ex) and 14X (m suffix) products is write-verify enabled.&lt;BR /&gt;</description>
      <pubDate>Wed, 20 Aug 2003 21:40:40 GMT</pubDate>
      <guid>https://community.hpe.com/t5/optical-jukeboxes-and-drives/why-does-l-amp-tt-disable-write-verify-and-write-cache/m-p/251952#M1917</guid>
      <dc:creator>CA877192</dc:creator>
      <dc:date>2003-08-20T21:40:40Z</dc:date>
    </item>
    <item>
      <title>Re: Why does L&amp;TT disable write-verify and write cache.</title>
      <link>https://community.hpe.com/t5/optical-jukeboxes-and-drives/why-does-l-amp-tt-disable-write-verify-and-write-cache/m-p/251953#M1918</link>
      <description>Mark: Thanks for your support on this!  I did determine that our application does disable write-cache (by design).  Also, I verified that our application also sets write-verify to enabled (via  force verify SCSI command).</description>
      <pubDate>Mon, 15 Sep 2003 13:48:59 GMT</pubDate>
      <guid>https://community.hpe.com/t5/optical-jukeboxes-and-drives/why-does-l-amp-tt-disable-write-verify-and-write-cache/m-p/251953#M1918</guid>
      <dc:creator>noka</dc:creator>
      <dc:date>2003-09-15T13:48:59Z</dc:date>
    </item>
  </channel>
</rss>

