On Mon, 2009-03-09 at 02:36 -0600, 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 > - 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 > > Disadvantages: > - UNMAP gets less testing Also disadvantages: UNMAP will not work unless trim is pulled back out of libata again ... which makes this look a bit like a temporary hack. If we're going to get this working, we might as well do the job properly. Even if we don't quite know what UNMAP looks like, all we need is for the SAT to work on our approximation. As I've said before, I don't like the bio based approach. I think you leak a page on every trim command doing it (why? because the kernel mapped bios have special bio->end_io routines to collect and free the pages, you have no such routine). I think this is also a reflection of the fact that our discard structure isn't quite complete in practice. We need some sort of tear down to allow us to free the allocated parameter list for the command. James -- 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
