Christoph Hellwig wrote:
On Sun, Aug 16, 2009 at 10:52:07AM -0500, James Bottomley wrote:
However, the enterprise has been doing UNMAP for a while, so we can draw
inferences from them since the SSD FTL will operate similarly. For
them, UNMAP is the same cost in terms of time regardless of the number
of extents. The reason is that it's moving the blocks from the global
in use list to the global free list. Part of the problem is that this
involves locking and quiescing, so UNMAP ends up being quite expensive
to the array but constant in terms of cost (hence they want as few
unmaps for as many sectors as possible).
How are they doing the unmaps? Using something similar to Mark's wiper
script and using SG_IO? Because right now we do not actually implement
UNMAP support in the kernel. I'd really love to test the XFS batched
discard support with a real UNMAP implementation.
The sg3_utils version 1.28 beta at http://sg.danny.cz/sg/
has a new sg_unmap utility and the previous release
included sg_write_same with Unmap bit support.
sg_readcap has been updated to show the TPE and TPRZ bits.
There is a new SCSI GET LBA STATUS command coming
(approved at the last t10 meeting, awaiting the next
SBC-3 draft). That will show the mapped/unmapped
status of logical blocks in a range of LBAs. I can
add a utility for that as well.
Doug Gilbert
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
