I will not be able to attend the call tomorrow, so I will offer my opinions
on the T10 reflector.
(a) I don't see any point to doing a 12 byte TRIM command. The 16 byte
command is more future proof and any SCSI system (except maybe ATAPI) that
can do 10 and 12 byte commands can also do 16 byte commands.
(b) Likewise I don't see any point to a 32 byte TRIM command. The extra
fields in the CDB are for checking Protection Information fields attached
to user data; since the trim command won't transfer any user data these
fields add no value.
(c) You mention things like "checking protection information data before
trimming" or doing a verify operation before trimming? This is a pointless
waste of time for a bunch of blocks that you wish to delete. All you really
care about is that only good blocks are reused in the future, when new
information is written. Let the storage device's scrubbing or wear leveling
algorithms take care of that.
(d) I'm not sure why you don't like the T13 approach, where multiple
extents can be trimmed in one command instead of having to send a separate
command for each extent to be trimmed. If you tell me that when a person
goes to the GUI file manager and marks 10 files for deletion, some of which
might be fragmented into several extends, the operating system will only
trim one extent at a time (waiting for each to be trimmed before doing the
next) rather than combining multiple extents into one interface command
then perhaps there is no advantage to being able to do multiple extents.
The advantage of multiple extents in one command is using less interface
bus bandwidth. The only disadvantage is error recovery; if the command
fails or is aborted for other reasons it is messier because the host has to
figure out which (if any) of the extents were done and which have to be
retried. I hope you will expound on your reason(s) for liking the one
extent at a time approach.
Matthew Wilcox
<matthew@xxxxxx>
Sent by: To
owner-t10@xxxxxxx "Knight, Frederick"
No Phone Info <Frederick.Knight@xxxxxxxxxx>
Available cc
t10@xxxxxxx,
linux-scsi@xxxxxxxxxxxxxxx,
10/02/2008 10:24 dougg@xxxxxxxxxx
AM Subject
Alternative TRIM proposal
* From the T10 Reflector (t10@xxxxxxx), posted by:
* Matthew Wilcox <matthew@xxxxxx>
*
There's a meeting tomorrow to discuss the T10 TRIM command. The current
proposal can be seen at http://t10.org/ftp/t10/document.08/08-149r2.pdf
A related document (discussing READ after TRIM) can be found at
http://t10.org/ftp/t10/document.08/08-347r1.pdf
I'm not keen on the 'pass a list of blocks to be trimmed' model. I would
prefer TRIM to be a real command like READ or WRITE. To that end, here
are my notes on creating such commands, followed by an actual proposal.
I would welcome feedback on this, and it'd be most useful if such feedback
occurred within the next 24 hours so I can refine the proposal before
the meeting.
Notes
=====
SBC-3 specifies 6, 10, 12, 16 and 32 byte commands for each of READ and
WRITE as well as 10, 12, 16 and 32 byte commands for VERIFY. While it
is tempting to only define a 32-byte TRIM command, that would prevent
older controllers from supporting TRIM, as well as being wasteful in the
on-wire encoding. All drivers in Linux support at least 12-byte commands,
so I think we can avoid defining 6 and 10 byte variants of TRIM in order
to conserve the number of operation codes required for this proposal.
The 12-byte commands allow 32 bits for LBA and 32 bits for transfer length
(remember these are specified in sectors (normally 512 bytes), so support
drives up to 2TB in size). The 16-byte commands expand the LBA size
to 64-bit, supporting drive sizes over 9000 Exabytes (8192 exbibytes,
I suppose). The 32-byte commands add support for application tags.
The commands also include various fields which may or may not make sense
for TRIM. Here's a list:
WRPROTECT | The application may want the device to check protection
RDPROTECT | information before allowing the TRIM to succeed. This is
VRPROTECT | the same case as VERIFY with BYTCHK=0. See table 67 in
| SAM 3 r14.
DPO | Disable Page Out is not relevant to TRIM since the blocks
| are being discarded. Checking application tags may
require
| the blocks to be accessed, but they can always be
discarded
| immediately. Recommend this bit be reserved.
FUA | I don't see a reason to force unit access, recommend
these
FUA_NV | bits be reserved.
BYTCHK | There might be a case to be made for allowing the device
| to discard only if the data is still what it used to be,
| but this would add additional complexity and I don't know
| if it's worth it. Reserve this bit.
GROUP NUMBER | I can see it being useful to account TRIMs to different
| groups and produce statistics about them, so recommend
that
| GROUP NUMBER be specified as it is for other commands.
CONTROL | All commands shall contain the CONTROL byte as specified
by
| SAM 4.
Proposal
========
Define three new commands, TRIM (12), TRIM (16) and TRIM (32):
TRIM (12)
byte 0 OPERATION CODE (to be assigned)
byte 1 bits 7-5: VRPROTECT, bits 4-0: Reserved
byte 2-5 LOGICAL BLOCK ADDRESS
byte 6-9 TRANSFER LENGTH
byte 10 bits 7-5: Reserved, bits 4-0: GROUP NUMBER
byte 11 CONTROL
TRIM (16)
byte 0 OPERATION CODE (to be assigned)
byte 1 bits 7-5: VRPROTECT, bits 4-0: Reserved
byte 2-9 LOGICAL BLOCK ADDRESS
byte 10-13 TRANSFER LENGTH
byte 14 bits 7-5: Reserved, bits 4-0: GROUP NUMBER
byte 15 CONTROL
TRIM (32)
byte 0 OPERATION CODE (7Fh)
byte 1 CONTROL
byte 2-5 Reserved
byte 6 bits 7-5: Reserved, bits 4-0: GROUP NUMBER
byte 7 ADDITIONAL CDB LENGTH (18h)
byte 8-9 SERVICE ACTION (to be assigned)
byte 10 bits 7-5: VRPROTECT, bits 4-0: Reserved
byte 11 Reserved
byte 12-19 LOGICAL BLOCK ADDRESS
byte 20-23 EXPECTED INITIAL LOGICAL BLOCK REFERENCE TAG
byte 24-25 EXPECTED LOGICAL BLOCK APPLICATION TAG
byte 26-27 LOGICAL BLOCK APPLICATION TAG MASK
byte 28-31 TRANSFER LENGTH
--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo@xxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
