RE: [t13] WRITE LONG, SCT Write Long, and WRITE WRONG EXT

[Sheffield, Robert L]

Curtis,   I think when RAID vendors begin to use the WRITE WRONG commands in practice, we'll find the capability it offers will be weak with respect to what's needed for robust RAID algorithms. It's hard to explain withoug going into a detailed description of various ways to use block-wise metadata in RAID algorithms, but here are a few basic points: A RAID controller generally needs to know the difference between a sector deliberately marked bad versus an actual defective sector. A sector deliberately marked bad has implications to stripe coherency. It's extremely helpful to embed metadata (beyond the bad block indication) to help deal with tracking and restoring stripe coherency, particularly when such conditions are encountered during the course of background operations such as RAID level migration or capacity expansion. Once the idea of attaching sector-wise metadata is implemented, there are a number of very valuable uses for that metadata even when the data in the sector is good - particularly when the sector contains parity information and the corresponding stripe is in some sort of "special" state for one reason or another.   I don't see that the WRITE WRONG and READ WRONG commands, as currently defined, provide these capabilities, and so I think their use may be limited as a result. Something more along the lines of the Data Protection featues defined in SCSI SBC-2 would be much more powerful.   Perhaps a lesser level of capability is "good enough" for ATA, but I would suggest at least providing the means to distinguish between a sector deliberately marked bad and a defective sector, and the means to embed a few bytes (or more) of metadata in a block explicitly marked bad.   Bob From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Curtis Stevens Sent: Thursday, June 09, 2005 11:13 AM To: forum@t13.org Subject: RE: [t13] WRITE LONG, SCT Write Long, and WRITE WRONG EXT Bob/Rob               One of the reasons for moving to write wrong is that drive manufacturers are moving to permuted ECC.  When this transition is complete, there is no real meaning to be found in the erroneous data.  There will be no real ability to do heroic recovery outside the drive.  Write Wrong provides a simple way to mark a sector as bad, one of the major uses for write long.               The ATA community is also beginning the transition to a larger sector size.  This may have some effect on STP.  Write Wrong maintains the ability to mark a single 512 byte unit as bad, even though the media sector size may be 1K or 4K.     ------------------------------------------------- Curtis E. Stevens 20511 Lake Forest Drive #C-214D Lake Forest, California 92630 Phone: 949-672-7933 Cell: 949-307-5050 E-Mail: [EMAIL PROTECTED] Ambition is a poor excuse for not having enough sense to be lazy. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sheffield, Robert L Sent: Wednesday, June 08, 2005 5:48 PM To: Elliott, Robert (Server Storage); forum@t13.org Subject: RE: [t13] WRITE LONG, SCT Write Long, and WRITE WRONG EXT   Along the thread of being helpful to SCSI-to-ATA Translation (SAT): There's a related capability I think should be addressed ahead of the Read/Write Long capabilities.   The SCSI SBC-2 standard defines the TB bit in the Read/Write error recovery mode page as follows: A transfer block (TB) bit set to zero specifies that the device server shall not transfer a logical block to the data-in buffer if the logical block is not recovered within the recovery limits specified. A TB bit set to one specifies that the device server shall transfer a logical block to the data-in buffer before returning CHECK CONDITION status if the logical block is not recovered within the recovery limits specified. The data returned in this case is vendor-specific. The TB bit does not affect the action taken for recovered data. The net effect is the ability of a SCSI disk drive to transfer a block of data read from the media, even though there were uncorrectable/unrecoverable errors. Presumably (though not specified) the disk would return data that matches the orignially written data except for the bits/bytes affected by the media defect. Without a comparable feature in the ATA command set, the only way SAT device can SATisfy (sorry) the required behavior for a TB set to one is to manufacture the data - which doesn't really meet the spirit of what the TB feature was intended to accomplish.   Perhaps this could be done with some form of read/write long (or wrong), but the problem with those commands is the ECC algorithm applied is vendor-specific, and the host application needs to comprehend the vendor-specific aspects of the device ECC algorithm in order to reliably "plant" bad ECC that can be distinguished from an actual bad block. I'd like to see a standard ATA command that allows retrieval of whatever good information can be extracted from a bad block that isn't dependent on vendor-specific aspects of the ECC algorithm applied (i.e. doesn't transfer the ECC bytes).   Bob   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Elliott, Robert (Server Storage) Sent: Wednesday, June 08, 2005 5:11 PM To: forum@t13.org Subject: [t13] WRITE LONG, SCT Write Long, and WRITE WRONG EXT ATA offers quite a few ways to perform WRITE LONG and READ LONG functionality.   1. ATA-3 defined WRITE LONG (command codes 32h and 33h) and READ LONG (command codes 22h and 23h), including a note that "The committe is considering removing READ LONG and WRITE LONG commands in a future ATA standard." The commands are obsolete in ATA-4.   2. The SCT (SMART Command Transport) technical report defines a way to implement WRITE LONG and READ LONG commands through SMART log pages (supporting 48-bit LBAs).   Command: SMART READ LOG, SMART WRITE LOG, READ LOG EXT, or WRITE LOG EXT Log address: E0h (Writes) or E1h (Reads) SCT Function code: 0001h (Read Long) and 0002h (Write Long)   Those log addresses are marked "Reserved" in ata7v1r4b.   3. Proposal e02126, defining new WRITE WRONG EXT and READ WRONG EXT commands, has apparently been resurrected.     Any chance of converging on one method?  If WRITE WRONG continues, then a SCSI equivalent would be helpful for the SCSI-to-ATA Translation (SAT) project.   Since these commands each address a single logical block, it's unclear how well they will work with long physical sectors, where the ECC bytes are shared by more than one logical block.   -- Rob Elliott, [EMAIL PROTECTED] Hewlett-Packard Industry Standard Server Storage Advanced Technology https://ecardfile.com/id/RobElliott