solid state mode/ vpd/ event work

Pat LaVarre plavarre at lexarmedia.com
Wed Dec 22 01:52:10 PST 2004


* From the T10 Reflector (t10 at t10.org), posted by:
* "Pat LaVarre" <plavarre at lexarmedia.com>
*
This is a multi-part message in MIME format.

------_=_NextPart_001_01C4E80B.E7D800CE
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Ralph W:

> > 5.3.3  SBC-2: Proposal for USB Solid State Drive Mode Sense
> > specification (04-362r0) [Furuhjelm]
> > ftp://ftp.t10.org/t10/document.04/04-362r0.pdf
<ftp://ftp.t10.org/t10/document.04/04-362r0.pdf>=20
> ...
> The brief list quoted in the most recent message is
> (as best as I understand it) the advice given to Mr.
> Hellmold by the CAP working group in Austin.

Yes, that's the advice I'm trying to understand.  I'm trying to jump in
now to help Steffen Hellmold.  Not sure I have helped, yet. :)

The news from the November CAP WG included the idea that we've got too
much work here in front of us for Steffen/ Martin Furuhjelm to handle
alone.  I hired in on December 6 to help Lexar respond more rapidly to
CAP WG folk like yourself, willing to make time to volunteer feedback.

> My recollection further suggests that the CAP group has yet
> to come to grips with the best way to handle the Health
> Indicator. Further wrestling with specifics appears to be
> necessary.

How should I further wrestle with those specifics?  Must I wait to
attend the CAP WG in person, or can I help in advance?

Another try from me at helping in advance is to mention the specific:

---

When I try to divide the solid state data of the Lexar proposal into
three parts, ...

I find almost every field lands into "2) Unchangeable data belongs in a
VPD page", because we're describing either the target device or the
inserted medium, not something more dynamic.

The "Storage Capacity Status" field when calculated by the host is the
only field I saw fit the category "1) Data that the host wants to set
belongs in a Mode page".  The "Storage Capacity Status" field when
calculated by the device and the "Media Health Status" field were the
only two fields I saw fit the category "3) Data that needs to be polled
(i.e., the Health Indicator) belongs in a Log page (with threshold
enabled), or polled with a Request Sense command, or polled with a TBD
specialized command".  All the remaining fields I saw were "2)
Unchangeable data", which I may have been told "belongs in a VPD page".

I say "may have been told" because that's the division into three parts
that I see if I take "unchangeable" to mean unchangeable from one plug
in of the device til the next plug in, or from one insert of a medium
til the next insertion.  I'm not yet certain that's how unchangeable we
want "unchangeable" to be?  I don't know myself yet now of anything in
t10 that we require to remain unchanged across more than one power =
cycle
of the device, except for devices that we require to be world wide
unique.

All the remaining fields of the proposal look to me like they vary only
by disc (e.g., is the erase block related to page as in NAND flash or
not).  I'm not yet certain if we want to work to discriminate fields
that actually vary only by device from fields that only vary by disc.
Few to zero of these fields actually vary only by device.  The fields
"WT - Device supports Write Through Cache (FUA)" and "WC - Device
implements a Write Cache (Additional Cache parameters are in mode sense
page 6 or 8)", being newly invented, were the only fields I saw could =
be
set up to vary only by device firmware.  But I'd say those also more
naturally vary by disc - that allows the device to run one firmware per
storage medium technology, rather than forcing an otherwise unnecessary
commonality across those firmware images.  Do we have a reason to push
for data to vary only by device, rather than by medium?

> I have no idea what "Massively distributed hosts" has to
> do with the proposal.

MDH is jargon copied from a different social circle, sorry.

I mean to say, my employer makes devices.  I want to plug those devices
into Windows/ Mac/ Linux/ Solaris/ boot BIOS/ etc.  I need to define =
new
ways of talking that fit into that long established, somewhat =
unwritten,
legacy of hosts whose designs ship in the millions - consumer, retail,
not just one off, not just middle volumes.

> Is the goal that only Distributed
> Cluster systems with large numbers of processing nodes
> are the only initiators that care about the solid state
> disk information?

Ouch, no, sorry, I meant MDH as defined above: hosts sold to consumers,
not hosts whose constituent elements are widely separated.

> What is "...from any PDT x 0E 07 05 04 00 device"? What is
> a PDT? Sorry, but PDT is not in my acronyms glossary.

Thanks for making time to say so, I did not know.

To me, PDT is "Peripheral Device Type" is mask x1F of byte 0 of op x12
"INQUIRY" data.  PDT in x 0E 07 04 00 =3D HDD/ Floppy/ Flash =3D RBC, =
SBC,
etc. from t10 and from SFF.  PDT =3D x05 =3D C/DVD =3D MMC from t10 and =
from
SFF.  What is the more popular way of talking about those deeply
significant bits, fetched always early in plug 'n play?

I mentioned those PDT in particular I need us to construct a newly
standard way of describing solid state parameters that fits into all
five of those legacy ways of talking.  PDT x00 =3D SBC matters to me =
most.
The others matter to me only by way of overlapping - only when hosts
give some advantage to describing an otherwise PDT x00 device in those
alternate ways.

> I fail to follow the logic that puts testing the mode page
> first and retrieving the VPD page second. Why not perform
> the "test" by retrieving the VPD page?

On reviewing the minutes of the CAP WG work of November, the main
surprise to me was this idea of dividing the solid state data into =
three
parts, reported by three separate commands.  I'm here trying to make
sense of that surprise.  I must need some fundamental education, else
the committee consensus would not have surprised me so.  Me, I thought
adding one mode page would work, same as Martin & Steffen apparently
did, before I arrived.

So far as I know, the Windows/ Mac/ Linux/ Solaris/ boot BIOS/ etc.
world has no legacy of making use of the VPD innovation - new in the
90's with SCSI 3, was it?  By contrast, those massively distributed
hosts do have a limited legacy of asking for missing mode pages.

I'm thinking t10 writes device standards, not host standards.  I'm
thinking we get farther with host folk when, in supporting documents or
in non-normative rationale, we explain how to fit the new standard into
the old ways.  I'm thinking we can more credibly argue to discover =
which
solid state storage supports a newly standard, now often missing, mode
page by first asking for that mode page, than by asking first for VPD
with a variation on the basic x 12 00 00 00 24 00 CDB that is a de =
facto
standard "INQUIRY".

Wrong or right, is my logic now coherent?

Is my now coherent logic still wrong?

> Most of the really
> interesting data will be in the VPD page (at least that was
> the impression I got from Mr. Hellmold's presentation). So,
> why not go for the gold up front?

Persuasively answered above now?

> Finally, I side 100% with Michael regarding the following
> statement "...inventing a new use for EVPD and yet another
> form of polling, ..." To me, this looks like a proposal
> to use a VPD page to contain data that is polled. Since
> such a plan would clearly violate the "Unchangeable data
> belongs in in a VPD page" guideline, I flat out cannot
> follow the proposal.

Help!  I mean only to be correctly understanding and then detailing the
three guidelines laid down by the November CAP WG.

I don't mean to be violating or revising those guidelines.  For the VPD
page, I propose only the "2) Unchangeable data" decided by the choice =
of
storage medium inserted, explicitly Not the "Storage Capacity Status"
and "Media Health Status" that change rapidly and unpredictably while
mounted.

How can I help?

Thanks again in advance,
Pat LaVarre
http://www.t10.org/ftp/t10/members.txt
<http://www.t10.org/ftp/t10/members.txt>=20

-----Original Message-----
From: owner-t10 at t10.org on behalf of Ralph O. Weber
Sent: Tue 12/21/2004 6:31 PM
To: t10 at t10.org
Subject: Re: solid state mode/ vpd/ event work

* From the T10 Reflector (t10 at t10.org), posted by:
* "Ralph O. Weber" <roweber at ieee.org>
*
Dear Mr. LaVarre,

The brief list quoted in the most recent message is
(as best as I understand it) the advice given to Mr.
Hellmold by the CAP working group in Austin.

Specifically:

1) Data that the host wants to set belongs in a Mode page.

2) Unchangeable data belongs in a VPD page.

3) Data that needs to be polled (i.e., the Health Indicator)
   belongs in a Log page (with threshold enabled), or polled
   with a Request Sense command, or polled with a TBD
   specialized command.

My recollection further suggests that the CAP group has yet
to come to grips with the best way to handle the Health
Indicator. Further wrestling with specifics appears to be
necessary.

However, like Michael Banther, I am totally flummoxed by
statements in the original posting.

I have no idea what "Massively distributed hosts" has to
do with the proposal. Is the goal that only Distributed
Cluster systems with large numbers of processing nodes
are the only initiators that care about the solid state
disk information?

What is "...from any PDT x 0E 07 05 04 00 device"? What is
a PDT? Sorry, but PDT is not in my acronyms glossary.

I fail to follow the logic that puts testing the mode page
first and retrieving the VPD page second. Why not perform
the "test" by retrieving the VPD page? Most of the really
interesting data will be in the VPD page (at least that was
the impression I got from Mr. Hellmold's presentation). So,
why not go for the gold up front?

Finally, I side 100% with Michael regarding the following
statement "...inventing a new use for EVPD and yet another
form of polling, ..." To me, this looks like a proposal
to use a VPD page to contain data that is polled. Since
such a plan would clearly violate the "Unchangeable data
belongs in in a VPD page" guideline, I flat out cannot
follow the proposal.

All the best,

.Ralph

Pat LaVarre wrote:

> I thought that's what the committee told me to do?  On review now, I
> see the meeting notes only say "can be represented" or "needs to be
> represented".  I took that English as a less confrontational way of
> saying "should be represented".  More specifically, I thought I was
> being told to:
>
> 1) Represent "Data that the host wants to set" "in a Mode page".
>
> 2) Represent "unchangeable data" "in a VPD page".
>
> 3) Represent "data that needs to be polled (e.g., the health
> indicator)" "by a Log page (with unit attention)" or "polling with
> Request Sense", or "polling with a specialized command".
>
> All that quoted text above comes from what "George Penokie noted" in
> the CAP WG Nov minutes:
> http://www.t10.org/ftp/t10/document.04/04-367r1.htm
<http://www.t10.org/ftp/t10/document.04/04-367r1.htm>=20
>
> The parts not quoted came from me think I was being shown the light =
of
> the correct way to proceed.  Have I misunderstood?  Help?
>
> Thanks again in advance, Pat LaVarre
>
> -----Original Message-----
> From: owner-t10 at t10.org on behalf of Banther, Michael
> Sent: Mon 12/20/2004 3:28 AM
> To: t10 at t10.org
> Subject: RE: solid state mode/ vpd/ event work
>
> I do not understand your comment below, 'By inventing a new use for
EVPD
> ....'  Do you intend to define a new VPD page to hold the 'read-only
> descriptive data?'
>
> Regards,
> Michael Banther
> Hewlett-Packard Ltd.
> Telephone +44 (117) 312-9503
>
>
> -----Original Message-----
> From: owner-t10 at t10.org [ mailto:owner-t10 at t10.org
<mailto:owner-t10 at t10.org> ] On Behalf Of Pat
> LaVarre
> Sent: 17 December 2004 17:36
> To: t10 at t10.org
> Subject: solid state mode/ vpd/ event work
>
> * From the T10 Reflector (t10 at t10.org), posted by:
> * "Pat LaVarre" <plavarre at lexarmedia.com>
> *
> Hello again, remember Me?  We've now volunteered me to redraft the
> (04-362r0.pdf from Lexar) proposal for vpd/ mode/ etc. definitions
that
> help the host tune its use of solid-state storage.  I hope to see
ya'll
> in person at the next CAP WG.
>
> I'm working face to face with people who attended the November CAP =
WG,
> also from the written minutes that I quote below.  For example, I =
plan
> to begin by answering the request to divide the solid-state data into
> three categories: a) rewritable settings data, b) read-only
descriptive
> data, and c) pollable event data.
>
> But if I may, I'd first like to take a moment to confirm I understand
> the overall approach.  I hear we the committee saying Four things:
>
> ---
>
> 1) Massively distributed hosts may choose to adopt this new standard
by
> beginning with the negligible risk of trying to fetch the newly
standard
> solid-state mode page, from any PDT x 0E 07 05 04 00 device.
>
> 2) With devices that do not make the new page available, the system
will
> survive as it already does when the host looks for other mode pages
with
> less than universal support, such as the code x05 HDD C:H:S page or
the
> x2A C/DVD media compatibility page.
>
> 3) After confirming a particular device does make the new page
> available, the host may proceed to fetch the read-only descriptive
data
> by trying op x12 INQUIRY with the byte 1 mask x01 EVPD bit of the CDB
> set.  The host may alter the rewritable settings via Mode Select, in
> particular choosing to enable the new unit attention or not.
Thereafter
> the host may poll for events.
>
> 4) By inventing a new use for EVPD and yet another form of polling, =
we
> might break (intrinsically fragile) opaque bridge chips, but that's a
> cost the device folk who wish to establish this new standard can =
agree
> to pay before shipping a device that does make the new page =
available.
>
> ---
>
> Is that our thinking?
>
> Thanks in advance, hope this helps, Pat LaVarre
> http://www.t10.org/ftp/t10/members.txt
<http://www.t10.org/ftp/t10/members.txt>=20
>
> --- Background ---
>
> http://t10.org <http://t10.org>=20
>
> http://t10.org/t10_mins.htm <http://t10.org/t10_mins.htm>=20
>
> 04-367r1 Minutes of CAP Working Group - Nov 9-10, 2004
> http://www.t10.org/ftp/t10/document.04/04-367r1.htm
<http://www.t10.org/ftp/t10/document.04/04-367r1.htm>=20
>
> 5.3.3  SBC-2: Proposal for USB Solid State Drive Mode Sense
> specification (04-362r0) [Furuhjelm]
> ftp://ftp.t10.org/t10/document.04/04-362r0.pdf
<ftp://ftp.t10.org/t10/document.04/04-362r0.pdf>=20
>
> Steffen Hellmold presented a proposal for defining a mode page for =
USB
> solid-state drives (04-362r0). The group recommended using a VPD page
> instead of a mode page for most of the proposed data, as well as =
other
> changes in the proposal.
>
> George Penokie noted that the proposal contains three types data:
>
>
> o      Unchangeable data that can be represented in a VPD page
>
> o      Data that the host wants to set that can be represented in a
Mode
> page
>
> o      Data that needs to be polled (e.g., the health indicator) =
which
> needs to be represented by a Log page (with unit attention), polling
> with Request Sense, or polling with a specialized command
>
> Steffen agreed to prepare a revised proposal for consideration at the
> next meeting.
>
> ...
>
> ---
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
>



*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org



------_=_NextPart_001_01C4E80B.E7D800CE
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">

 RE: solid state mode/ vpd/ event work Ralph W:
 
> > 5.3.3  SBC-2: Proposal for USB Solid State Drive Mode = Sense
 > > specification (04-362r0) [Furuhjelm]
 > > ftp://ftp.t10.or= g/t10/document.04/04-362r0.pdf
 > ...
 > The brief list quoted in the most recent message is
 > (as best as I understand it) the advice given to Mr.
 > Hellmold by the CAP working group in Austin.
 
Yes, that's the advice I'm trying to understand.  I'm trying to = jump in now to help Steffen Hellmold.  Not sure I have helped, = yet. :)
 
The news from the November CAP WG included the idea that we've got too = much work here in front of us for Steffen/ Martin Furuhjelm to handle = alone.  I hired in on December 6 to help Lexar respond more = rapidly to CAP WG folk like yourself, willing to make time to volunteer = feedback.
 
> My recollection further suggests that the CAP group has yet
 > to come to grips with the best way to handle the Health
 > Indicator. Further wrestling with specifics appears to be
 > necessary.
 
How should I further wrestle with those specifics?  Must I wait to = attend the CAP WG in person, or can I help in advance?
 
Another try from me at helping in advance is to mention the = specific:
 
---
 
When I try to divide the solid state data of the Lexar proposal into = three parts, ...
 
I find almost every field lands into ;2) Unchangeable data belongs = in a VPD page;, because we're describing either the target device = or the inserted medium, not something more dynamic.
 
The ;Storage Capacity Status; field when calculated by the = host is the only field I saw fit the category ;1) Data that the = host wants to set belongs in a Mode page;.  The ;Storage = Capacity Status; field when calculated by the device and the = ;Media Health Status; field were the only two fields I saw = fit the category ;3) Data that needs to be polled (i.e., the = Health Indicator) belongs in a Log page (with threshold enabled), or = polled with a Request Sense command, or polled with a TBD specialized = command;.  All the remaining fields I saw were ;2) = Unchangeable data;, which I may have been told ;belongs in a = VPD page;.
 
I say ;may have been told; because that's the division into = three parts that I see if I take ;unchangeable; to mean = unchangeable from one plug in of the device til the next plug in, or = from one insert of a medium til the next insertion.  I'm not yet = certain that's how unchangeable we want ;unchangeable; to = be?  I don't know myself yet now of anything in t10 that we = require to remain unchanged across more than one power cycle of the = device, except for devices that we require to be world wide unique.
 
All the remaining fields of the proposal look to me like they vary only = by disc (e.g., is the erase block related to page as in NAND flash or = not).  I'm not yet certain if we want to work to discriminate = fields that actually vary only by device from fields that only vary by = disc.  Few to zero of these fields actually vary only by = device.  The fields ;WT - Device supports Write Through Cache = (FUA); and ;WC - Device implements a Write Cache (Additional = Cache parameters are in mode sense page 6 or 8);, being newly = invented, were the only fields I saw could be set up to vary only by = device firmware.  But I'd say those also more naturally vary by = disc - that allows the device to run one firmware per storage medium = technology, rather than forcing an otherwise unnecessary commonality = across those firmware images.  Do we have a reason to push for = data to vary only by device, rather than by medium?
 
> I have no idea what ;Massively distributed hosts; has = to
 > do with the proposal.
 
MDH is jargon copied from a different social circle, sorry.
 
I mean to say, my employer makes devices.  I want to plug those = devices into Windows/ Mac/ Linux/ Solaris/ boot BIOS/ etc.  I need = to define new ways of talking that fit into that long established, = somewhat unwritten, legacy of hosts whose designs ship in the millions = - consumer, retail, not just one off, not just middle volumes.
 
> Is the goal that only Distributed
 > Cluster systems with large numbers of processing nodes
 > are the only initiators that care about the solid state
 > disk information?
 
Ouch, no, sorry, I meant MDH as defined above: hosts sold to consumers, = not hosts whose constituent elements are widely separated.
 
> What is ;...from any PDT x 0E 07 05 04 00 device;? What = is
 > a PDT? Sorry, but PDT is not in my acronyms glossary.
 
Thanks for making time to say so, I did not know.
 
To me, PDT is ;Peripheral Device Type; is mask x1F of byte 0 = of op x12 ;INQUIRY; data.  PDT in x 0E 07 04 00 =3D HDD/ = Floppy/ Flash =3D RBC, SBC, etc. from t10 and from SFF.  PDT =3D = x05 =3D C/DVD =3D MMC from t10 and from SFF.  What is the more = popular way of talking about those deeply significant bits, fetched = always early in plug 'n play?
 
I mentioned those PDT in particular I need us to construct a newly = standard way of describing solid state parameters that fits into all = five of those legacy ways of talking.  PDT x00 =3D SBC matters to = me most.  The others matter to me only by way of overlapping - = only when hosts give some advantage to describing an otherwise PDT x00 = device in those alternate ways.
 
> I fail to follow the logic that puts testing the mode page
 > first and retrieving the VPD page second. Why not perform
 > the ;test; by retrieving the VPD page?
 
On reviewing the minutes of the CAP WG work of November, the main = surprise to me was this idea of dividing the solid state data into = three parts, reported by three separate commands.  I'm here trying = to make sense of that surprise.  I must need some fundamental = education, else the committee consensus would not have surprised me = so.  Me, I thought adding one mode page would work, same as Martin = & Steffen apparently did, before I arrived.
 
So far as I know, the Windows/ Mac/ Linux/ Solaris/ boot BIOS/ etc. = world has no legacy of making use of the VPD innovation - new in the = 90's with SCSI 3, was it?  By contrast, those massively = distributed hosts do have a limited legacy of asking for missing mode = pages.
 
I'm thinking t10 writes device standards, not host standards.  I'm = thinking we get farther with host folk when, in supporting documents or = in non-normative rationale, we explain how to fit the new standard into = the old ways.  I'm thinking we can more credibly argue to discover = which solid state storage supports a newly standard, now often missing, = mode page by first asking for that mode page, than by asking first for = VPD with a variation on the basic x 12 00 00 00 24 00 CDB that is a de = facto standard ;INQUIRY;.
 
Wrong or right, is my logic now coherent?
 
Is my now coherent logic still wrong?
 
> Most of the really
 > interesting data will be in the VPD page (at least that was
 > the impression I got from Mr. Hellmold's presentation). So,
 > why not go for the gold up front?
 
Persuasively answered above now?
 
> Finally, I side 100% with Michael regarding the following
 > statement ;...inventing a new use for EVPD and yet = another
 > form of polling, ...; To me, this looks like a proposal
 > to use a VPD page to contain data that is polled. Since
 > such a plan would clearly violate the ;Unchangeable data
 > belongs in in a VPD page; guideline, I flat out cannot
 > follow the proposal.
 
Help!  I mean only to be correctly understanding and then = detailing the three guidelines laid down by the November CAP WG.
 
I don't mean to be violating or revising those guidelines.  For = the VPD page, I propose only the ;2) Unchangeable data; = decided by the choice of storage medium inserted, explicitly Not the = ;Storage Capacity Status; and ;Media Health Status; = that change rapidly and unpredictably while mounted.
 
How can I help?
 
Thanks again in advance,
 Pat LaVarre
 http://www.t10.org/ftp/t= 10/members.txt
 
-----Original Message-----
 From: owner-t10 at t10.org on behalf of Ralph O. Weber
 Sent: Tue 12/21/2004 6:31 PM
 To: t10 at t10.org
 Subject: Re: solid state mode/ vpd/ event work
 
* From the T10 Reflector (t10 at t10.org), posted by:
 * ;Ralph O. Weber; <roweber at ieee.org>
 *
 Dear Mr. LaVarre,
 
The brief list quoted in the most recent message is
 (as best as I understand it) the advice given to Mr.
 Hellmold by the CAP working group in Austin.
 
Specifically:
 
1) Data that the host wants to set belongs in a Mode page.
 
2) Unchangeable data belongs in a VPD page.
 
3) Data that needs to be polled (i.e., the Health Indicator)
    belongs in a Log page (with threshold enabled), or = polled
    with a Request Sense command, or polled with a TBD
    specialized command.
 
My recollection further suggests that the CAP group has yet
 to come to grips with the best way to handle the Health
 Indicator. Further wrestling with specifics appears to be
 necessary.
 
However, like Michael Banther, I am totally flummoxed by
 statements in the original posting.
 
I have no idea what ;Massively distributed hosts; has to
 do with the proposal. Is the goal that only Distributed
 Cluster systems with large numbers of processing nodes
 are the only initiators that care about the solid state
 disk information?
 
What is ;...from any PDT x 0E 07 05 04 00 device;? What = is
 a PDT? Sorry, but PDT is not in my acronyms glossary.
 
I fail to follow the logic that puts testing the mode page
 first and retrieving the VPD page second. Why not perform
 the ;test; by retrieving the VPD page? Most of the really
 interesting data will be in the VPD page (at least that was
 the impression I got from Mr. Hellmold's presentation). So,
 why not go for the gold up front?
 
Finally, I side 100% with Michael regarding the following
 statement ;...inventing a new use for EVPD and yet another
 form of polling, ...; To me, this looks like a proposal
 to use a VPD page to contain data that is polled. Since
 such a plan would clearly violate the ;Unchangeable data
 belongs in in a VPD page; guideline, I flat out cannot
 follow the proposal.
 
All the best,
 
.Ralph
 
Pat LaVarre wrote:
 
> I thought that's what the committee told me to do?  On review = now, I
 > see the meeting notes only say ;can be represented; or = ;needs to be
 > represented;.  I took that English as a less = confrontational way of
 > saying ;should be represented;.  More specifically, = I thought I was
 > being told to:
 >
 > 1) Represent ;Data that the host wants to set; ;in = a Mode page;.
 >
 > 2) Represent ;unchangeable data; ;in a VPD = page;.
 >
 > 3) Represent ;data that needs to be polled (e.g., the = health
 > indicator); ;by a Log page (with unit attention); = or ;polling with
 > Request Sense;, or ;polling with a specialized = command;.
 >
 > All that quoted text above comes from what ;George Penokie = noted; in
 > the CAP WG Nov minutes:
 > http://www.= t10.org/ftp/t10/document.04/04-367r1.htm
 >
 > The parts not quoted came from me think I was being shown the = light of
 > the correct way to proceed.  Have I misunderstood?  = Help?
 >
 > Thanks again in advance, Pat LaVarre
 >
 > -----Original Message-----
 > From: owner-t10 at t10.org on behalf of Banther, Michael
 > Sent: Mon 12/20/2004 3:28 AM
 > To: t10 at t10.org
 > Subject: RE: solid state mode/ vpd/ event work
 >
 > I do not understand your comment below, 'By inventing a new use = for EVPD
 > ....'  Do you intend to define a new VPD page to hold the = 'read-only
 > descriptive data?'
 >
 > Regards,
 > Michael Banther
 > Hewlett-Packard Ltd.
 > Telephone +44 (117) 312-9503
 >
 >
 > -----Original Message-----
 > From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On = Behalf Of Pat
 > LaVarre
 > Sent: 17 December 2004 17:36
 > To: t10 at t10.org
 > Subject: solid state mode/ vpd/ event work
 >
 > * From the T10 Reflector (t10 at t10.org), posted by:
 > * ;Pat LaVarre; <plavarre at lexarmedia.com>
 > *
 > Hello again, remember Me?  We've now volunteered me to = redraft the
 > (04-362r0.pdf from Lexar) proposal for vpd/ mode/ etc. definitions = that
 > help the host tune its use of solid-state storage.  I hope to = see ya'll
 > in person at the next CAP WG.
 >
 > I'm working face to face with people who attended the November CAP = WG,
 > also from the written minutes that I quote below.  For = example, I plan
 > to begin by answering the request to divide the solid-state data = into
 > three categories: a) rewritable settings data, b) read-only = descriptive
 > data, and c) pollable event data.
 >
 > But if I may, I'd first like to take a moment to confirm I = understand
 > the overall approach.  I hear we the committee saying Four = things:
 >
 > ---
 >
 > 1) Massively distributed hosts may choose to adopt this new = standard by
 > beginning with the negligible risk of trying to fetch the newly = standard
 > solid-state mode page, from any PDT x 0E 07 05 04 00 device.
 >
 > 2) With devices that do not make the new page available, the = system will
 > survive as it already does when the host looks for other mode = pages with
 > less than universal support, such as the code x05 HDD C:H:S page = or the
 > x2A C/DVD media compatibility page.
 >
 > 3) After confirming a particular device does make the new page
 > available, the host may proceed to fetch the read-only descriptive = data
 > by trying op x12 INQUIRY with the byte 1 mask x01 EVPD bit of the = CDB
 > set.  The host may alter the rewritable settings via Mode = Select, in
 > particular choosing to enable the new unit attention or not.  = Thereafter
 > the host may poll for events.
 >
 > 4) By inventing a new use for EVPD and yet another form of = polling, we
 > might break (intrinsically fragile) opaque bridge chips, but = that's a
 > cost the device folk who wish to establish this new standard can = agree
 > to pay before shipping a device that does make the new page = available.
 >
 > ---
 >
 > Is that our thinking?
 >
 > Thanks in advance, hope this helps, Pat LaVarre
 > http://www.t10.org/ftp/t= 10/members.txt
 >
 > --- Background ---
 >
 > http://t10.org
 >
 > http://t10.org/t10_mins.htm
= >
 > 04-367r1 Minutes of CAP Working Group - Nov 9-10, 2004
 > http://www.= t10.org/ftp/t10/document.04/04-367r1.htm
 >
 > 5.3.3  SBC-2: Proposal for USB Solid State Drive Mode = Sense
 > specification (04-362r0) [Furuhjelm]
 > ftp://ftp.t10.or= g/t10/document.04/04-362r0.pdf
 >
 > Steffen Hellmold presented a proposal for defining a mode page for = USB
 > solid-state drives (04-362r0). The group recommended using a VPD = page
 > instead of a mode page for most of the proposed data, as well as = other
 > changes in the proposal.
 >
 > George Penokie noted that the proposal contains three types = data:
 >
 >
 > o      Unchangeable data that can be = represented in a VPD page
 >
 > o      Data that the host wants to set = that can be represented in a Mode
 > page
 >
 > o      Data that needs to be polled = (e.g., the health indicator) which
 > needs to be represented by a Log page (with unit attention), = polling
 > with Request Sense, or polling with a specialized command
 >
 > Steffen agreed to prepare a revised proposal for consideration at = the
 > next meeting.
 >
 > ...
 >
 > ---
 >
 > *
 > * For T10 Reflector information, send a message with
 > * 'info t10' (no quotes) in the message body to = majordomo at t10.org
 >
 


*
 * For T10 Reflector information, send a message with
 * 'info t10' (no quotes) in the message body to majordomo at t10.org
 
------_=_NextPart_001_01C4E80B.E7D800CE--




More information about the T10 mailing list