Matthew Wilcox wrote:
On Sun, Mar 08, 2009 at 04:32:36PM -0500, James Bottomley wrote:
Actually, found the reason, blk_rq_map_kern will blast the original bio
from the request. You could fix this by chaining it back again at the
beginning. If that works, we could just wrap it into a block API to
prevent users from having to muck with bios.
How about constructing the TRIM entirely within libata? I won't be able
to test this patch until Oregon wakes up, but is this acceptable?
Advantages:
- Don't need to wait for T10 to finish designing UNMAP
The spc4r18.pdf and sbc3r18.pdf drafts were released recently
at t10.org. Both include thin provisioning items (e.g. see
UNMAP and WRITE SAME(16) in sbc3r18.pdf). So the design and
implementation of thin provisioning is pretty well done.
If you attempt to download these drafts you will be
challenged for a t10 login, select guest and supply a name
(e.g. "incits" is the name of the organization responsible
for this). I give "Linux" as my company.
Doug Gilbert
- Uses well-tested ATA_16 passthrough layer
- Changing the UNMAP implementation to do multiple ranges won't break TRIM
- Will be easier to adapt to a future separation of scsi and libata
[snip]
--
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
