On Thu, Aug 13, 2009 at 12:18 PM, James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > Actually, I think, if we go in-kernel, the discard might be better tied > into the block plugging mechanism. The real test might be no > outstanding commands and queue plugged, keep plugged and begin > discarding. I am very interested in this topic, as I have implemented UNMAP support in SCST and scst_local.c and ib_srp.c for one SSD vendor, as well as the block layer changes to have it work correctly (they were minor changes and based on Matthew's original TRIM or UNMAP patch from long ago). I believe that the performance was acceptable for them (I will have to check). I am also working on other, non-SSD, devices that are in a lower price range than the large storage arrays where both DISCARD/UNMAP (and WRITE SAME) would be useful in Linux. It also seems that Microsoft supports TRIM in Windows 7 if you switch it on, although that really only implies we should implement UNMAP support in our firmware and hook it up to existing mechanisms. I have logged internal enhancement bugs in bugzilla asking for both TRIM and UNMAP/WRITE SAME support, and although one environment is iSCSI in userland, and thus can be dealt with without support in the Linux kernel, there are use cases where DISCARD/UNMAP support in the Linux kernel would be useful. I would be very willing to make the firmware changes needed in our device to support UNMAP/WRITE SAME and to test changes to the Linux kernel to support same. I will go through this thread in more detail when I get back from my trip to Australia, but if there are any GIT trees around with nascent support in them I would love to know about them, as it will help my internal efforts to get UNMAP/WRITE SAME support implemented as well. -- Regards, Richard Sharpe -- 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
