ACS Coordinating Device Maintenance

Transcription

1 ACS Coordinating Device Maintenance July 28, 2010 Revision 2 Author: Nathan Obr 1 Microsoft Way Redmond, WA NatObr@Microsoft.com Coordinating Device Maintenance 1

2 Document Status Revision History Rev Date 00 May 10, 2010 Investigation of Scope and requirements 0 May 27, 2010 First Draft 1 June 08, 2010 Incorporated Ad Hoc meeting feedback 2 July 28, 2010 Incorporated feedback on the r1 revision from the June T13 meeting and Ad Hoc meetings feedback Coordinating Device Maintenance 2

3 1 Introduction The ever increasing demand for larger storage capacities through single devices with higher Areal Density has stretched the modern consumer storage device s ability to guarantee its own data integrity. Of course, consumer s requirements for data integrity have continued to remain high. Consequently, every sacrifice in media integrity necessary to improve storage capacity for a fixed form factor has to be compensated for by increasing complexity in the device s firmware. Once, a device s firmware s could address the new data integrity issues simply by verifying integrity at the time of performing a data operation, but within the last decade the physical limits of media have been pushed so far that such a direct approach is no longer sufficient. Modern device s firmware has to take additional secondary precautions, at regular intervals in order to maintain the stored data s integrity over time. In order to implement device maintenance for continued reliability on larger and larger capacities without significantly impacting performance, storage manufacturers are creating devices of unrivaled sophistication. The number of engineers, the demands of the manufacturing, and the complexity of the device systems used to land a block of data on a single physical sector of a device is greater than those used to land the first man on the moon. However, considering the frequency of device accesses and the amount of data in flight on a computing system at any given time, a more appropriate analogy would be landing all the fights of an international airport on the moon. With this level of complexity, it is not surprising that a poorly timed device maintenance can have a significant impact on a computing system. Modern storage devices often times find their maintenance schedules are forced to be out of harmony with the needs of the system as a whole, often causing inconsistent behaviors in responsiveness or performance and causing frustration for end users. 2 Scope The purpose of this proposal is to identify and catalog the current goals and requirements for the management of device maintance schedules into ATA8-ACS. All section changes are made with reference to d2015r3- ATAATAPI_Command_Set_-_2_ACS-2 and e08156r3-identify DEVICE data log. It establishes the scope and dataflow for coordinating device maintenace scheduling and it proposes mechanisms for the host to coordinate power loss, critical low power times and for the device to notify the host as to when the device would benefit from not being power managed. 3 Overview Despite the potential impact poorly timed device maintenance can have, modern storage protocols have almost no mechanism to influence or coordinate how or when modern storage devices schedule these critical tasks. End users, system manufacturers, software developers and firmware developers are all forced to work around the side effects of uncoordinated device maintenance. In every case issues manifest as frustration as entities attempt to perform actions without enough system or device context information. The solution, is to provide the missing context information by creating communication paths to the storage device to help manage when and how to perform its critical device maintenance without impacting the rest of the system Proposed Definition of Terms for Solution Idle Time: The duration of continuous time in which no ATA commands are sent to the device. This is the best time for a device to perform internal device maintenance. Device Maintenance Schedule: The frequency and duration that the device needs to perform internal device maintenance. Coordinating Device Maintenance 3

4 3.1.2 Coordinating Device Maintenance Requirements Support for Report Device Maintenance Schedule functionality shall be discoverable The Report Device Maintenance Schedule command reports how much idle time the device must have to perform internal device maintenance per an amount of time Coordinating Device Maintenance Process Flow During first enumeration 1. Host determines SET DATE & TIME EXT support in IDENTIFY DEVICE DATA 2. Host sends SET DATE & TIME EXT to the device which uses the time information to determine the length of time the device was without power and its new Device Maintance Schedule. Before any device power down 3. Host determines GET DEVICE MAINTENANCE SCHEDULE EXT support in IDENTIFY DEVICE DATA 4. If supported, during idle time, before issuing IDLE, STANDBY or SLEEP power commands, the host sends the GET DEVICE MAINTENANCE SCHEDULE EXT. a. If device has scheduled device maintenance, no follow up power management command should be issued by the host. until the alotted time specified for the maintenance has expired. b. If device does not have scheduled device maintenance, a follow up power management command may be issued by the host. SET DATE & TIME EXT GET DEVICE MAINTENANCE GET DEVICE MAINTENANCE GET DEVICE MAINTENANCE STANDBY time Coordinating Device Maintenance 4

5 4 Changes to ACS 4.1 Changes to clause 7 Command descriptions Changes to sub clause Input From the Device to the Host Data Structure Word O M S P F V Table 53 IDENTIFY DEVICE data TBD0 O B F Supported Capabilities TBD1 1 = DEVICE MAINTENANCE SCHEDULE EXT command is supported XX If bit TBD1 of word TBD0 is set to one, then the DEVICE MAINTENANCE SCHEDULE EXT command (see 7.TBD-A) is supported Changes to Table A.6 Supported Capabilities (page 03h) in e08156r3-identify DEVICE data log Offset Type Content TBD2 QWord Supported Capabilities TBD3 DEVICE MAINTENANCE SCHEDULE EXT is supported. Coordinating Device Maintenance 5

6 4.1.3 New clause 7 sub clause TBD-A 7.TBD-A GET MAINTENANCE SCHEDULE EXT TBD1, Non-Data 7.TBD-A.1 Feature Set This 48-bit command is for ATA devices (see 4.2). 7.TBD-A.2 The GET MAINTENANCE SCHEDULE EXT command allows the host to determine the current internal maintenance schedule of the device. The GET MAINTENANCE SCHEDULE EXT command shall not cause the device to change its power management state. 7.TBD-A.3 Inputs Name Feature Reserved Count Reserved LBA Reserved Device Bit :0 N/A Transport Dependent - See Reserved Command 7:0 TBD4 7.TBD-A.4 Normal Output See Table TBD-B. 7.TBD-A.5 Error Output See table Table 239 Generic Abort wo/icrc Error. Coordinating Device Maintenance 6

7 4.2 Changes to clause 9 Normal and Error Outputs Changes to the 9.2 Normal Outputs Table TBD-B GET DEVICE MAINTENANCE SCHEDULE EXT Normal Output Name Error Reserved Count Reserved LBA Bit 47:32 31:16 15:0 Total requested time - Identifies total number of seconds that the device is requesting for internal maintenance. The device shall set this field with the number of seconds that the host should avoid sending commands. Minimum requested time - Identifies the minimum number of seconds that the device should be left idle for internal maintenance. The device shall set this field with the number of seconds that the host should avoid sending commands in order for the device to complete the next internal maintenance operation. Maintenance budget time - Identifies number of minutes before a device may adopt vendor specific behavior to perform its internal maintenance. The device shall set this field with the number of minutes until the device vendor specific behavior that may cause performance degradation. Device Bit :0 N/A Transport Dependent - See Reserved Status Bit 7:6 Transport Dependent - See :1 Reserved 0 Error - See Coordinating Device Maintenance 7