ACS Proposal - Device Crashdump Collection

Transcription

1 ACS Proposal - Device Crashdump Collection June 08, 2010 Revision 1 Author: Nathan Obr 1 Microsoft Way Redmond, WA NatObr@Microsoft.com Device Crashdump Collection 1

2 Document Status Revision History Rev Date Description 00 May 10, 2010 Investigation of Scope and requirements 0 May 27, 2010 First Draft 1 June 08, 2010 Incorporated Ad Hoc meeting feedback Device Crashdump Collection 2

3 1 Introduction Storage is a critical component for computer systems and storage failures are one of the most expensive to address. This is particularly true for enterprise IT. Storage device are sophisticated systems with firmware codebase exceeding 0.5M lines of code, highly tuned electromagnetic media and constantly growing capacities. Greater complexity leads to greater difficulty in diagnosing failures, as well as greater opportunities derived from detailed device logging. One approach to addressing increasing system complexity is enabling a telemetry feedback loop reporting both health monitoring and component failure data for analysis. This benefits users via continuous improvement in manufacturing components as well as software behavior. For high volume manufactured components, telemetry should be thought of as part of the standard engineering process. 2 Scope The purpose of this proposal is to identify and catalog the current goals and requirements for the inclusion of a telemetry mechanism into ATA8-ACS. All section changes are made with reference to d2015r2- ATAATAPI_Command_Set_-_2_ACS-2. It establishes the scope and dataflow that the targeted telemetry system must provide and it proposes a mechanism for notifying and collecting telemetry data from the device at critical times. 3 Overview Enabling telemetry systems creates an opportunity to significantly improve storage experience and perceived reliability practically for all computer applications by enabling device vendors to get internal disk logs through any telemetry system. Creating a closed feedback loop for storage devices in the field will lead to better devices. Continuous connection of vendors to their users experiences can lead to improved quality of the firmware and components The remainder of this section provides a high level description of the feature through timing and dataflow, scope of requirements and goals, and terms defined as necessary. 3.1 Proposed Definition of Terms for Solution Collection Command: ATA method including command code and parameters that completely defines a single transfer of device crashdump data. Collection Data Header: The standard public portion of the payload data returned by the device in response to the Collection Command. Collection Data: The vendor specific private portion of the payload data returned by the device in response to the Collection Command. Crashdump Type: A configuration setting of the device which governs the amount and type of crashdump data returned in response to the Collection Command. Each type has a corresponding payload size which includes both the Collection Data Header and the Collection Data. 3.2 Device Crashdump Collection Requirements Support for the Collection Command along with Crashdump Types and their sizes shall be discoverable. The Collection Command shall include the size of data to be transferred. The Data size applies both the Collection Data Header and the Collection Data. The Collected Data shall be transferred with a single command The device and host shall both know the amount of time the device is given before the command will be aborted. Device Crashdump Collection 3

4 The Collection Data shall include a Collection Data Header which will include: Routing information that can be mapped 1:1 to an organization which should receive the data Routing information that describes the issue hit so that proper information/action can be applied to the failing system/device A device identification tag that can be used to trace a specific device to manufacturing data for that specific device Information identifying the host or device as the requester of the crashdump A version number that can be used by a receiving organization to determine how to interpret the private data. The device shall be able to notify the host of the presence of an existing crashdump and its corresponding size during enumeration in a manner that is not dependent on other commands being processed. 3.3 Device Crashdump Collection Process Flow 1. Host determines GPL support in IDENTIFY DEVICE DATA 2. Host determines Crashdump support and type sizes from reading GPL address 00h, page During enumeration host determines if there is Crashdump Data available by reading page 0, host collects the Crashdump Data by reading the corresponding number of pages. 4. During a system crash, the host triggers a Crashdump Data collection by reading the appropriate number of Crashdump Data pages. a. The device shall complete the command in less than 1 second. Once the Device has completed a command requesting any part of the Crashdump Data, the Crashdump Data shall be discarded. Device Crashdump Collection 4

5 4 Changes to ACS 4.1 Changes to Annex A - Log Definitions Changes to the Log Address Definitions Table Table A.2 Log Address Definitions Log Address Log Name Feature Set R/W Acess 00h Log directory, see A.2 and A.3 N/A RO GPL,SL 01h Summary SMART Error Log, see A.17 SMART RO SL 02h Comprehensive SMART Error Log, see A.4 SMART RO SL 03h Extended Comprehensive SMART Error Log, SMART RO GPL see A.7 04h Device Statistics, see A.5 N/A RO GPL,SL 05h Reserved 06h SMART Self-Test Log, see A.16 SMART RO SL 07h Extended SMART Self-Test Log, see A.9 SMART RO GPL 08h Power Conditions, see A.8 EPC RO GPL 09h Selective Self-Test Log, see A.15 SMART R/W SL 0A-0Ch Reserved N/A Reserved 0Dh LPS Mis-alignment log, see A.11 LPS RO GPL,SL 0Eh-0Fh Reserved 10h NCQ Command Error, see A.12 NCQ RO GPL 11h SATA Phy Event Counters, see A.14 N/A RO GPL 12h-17h Reserved for Serial ATA N/A Reserved 18h-1Fh Reserved N/A Reserved 20h Obsolete 21h Write Stream Error Log, see A.18 Streaming RO GPL 22h Read Stream Error Log, see A.13 Streaming RO GPL 23h Obsolete TBD0 Crashdump, see TBD-A N/A RO GPL TBD0-7Fh N/A Reserved 80h-9Fh Reserved SMART R/W GPL,SL A0h-9Fh Host Vendor Specific, see A.10 SMART VS GPL,SL E0h Device Vendor Specific, see A.6 SCT R/W GPL,SL E1h SCT Data Transfer, see 8.1 SCT R/W GPL,SL E2h-FFh Reserved N/A Key: RO - Log is read only. R/W - Log is read or written. R/W - Log is read or written. VS - Log is vendor specific thus read/write ability is vendor specific. GPL - General Purpose Logging SL - SMART Logging The device shall return command aborted if a GPL feature set command accesses a log that is marked only with SL. The device shall return command aborted if a SMART feature set command accesses a log that is marked only with GPL. Device Crashdump Collection 5

6 4.1.2 New Annex A subclause A TBD-A Crashdump Log (Log Address TBD0) TBD-A.1 Overview The Crashdump log is variable in length and consists of two parts. The 512 byte block at page zero consists of the Crashdump Data Header as defined in Table A.TBD2 The remainder of the Crashdump log consists of the crashdump Collection Data. Table A. TBD1 Crashdump Data Header Byte Description 0 Crashdump Source 1 Reserved 2 Crashdump Version 3 Reserved 4-7 Organization Identifier 8-31 Device Identifier Number of pages requested for collection Number of pages for a crashdump type Number of pages for a crashdump type Number of pages for a crashdump type Reserved Bucket Identifier TBD-A.2 Crashdump Source A value of 0 indicates that there is no material in the Crashdump Data pages. A value of 1 indicates that there is material in the Crashdump Data pages. TBD-A.3 Crashdump Version A version number that can be used by a receiving organization to determine how to interpret the Crashdump Data collected. TBD-A.4 Organization Identifier Routing information that can be mapped 1:1 to an organization which should receive the Crashdump Data collected. TBD-A.5 Device Identifier A device identification tag that can be used to associate a specific device to an organization s manufacturing data for that specific device. TBD-A.6 Number of pages requested for collection Identifies the number of pages requested by the host in the count register of the READ LOG command for this Log Address. TBD-A.7 Number of pages for crashdump type X Identifies the number of pages available within the Crashdump Data pages when the device is configured to produce a Crashdump of type X where X is 1, 2, or 3. TBD-A.8 Bucket Identifier Routing information that describes the issue hit so that proper information/action can be applied to the failing system/device. Device Crashdump Collection 6