On Sat, Feb 07, 2009 at 09:09:32AM -0600, James Bottomley wrote: > On Sat, 2009-02-07 at 09:53 -0500, Ric Wheeler wrote: > > I have been poked at by some vendors about the status of our support for > > the virtually/thinly provisioned luns since they are getting close to > > being able to test with real devices. > > With my LSF hat on, a certain array vendor might be sponsoring to get > the opportunity to raise this issue more fully. The impression (mostly > correct) is that we're thinking about trim/unmap purely from the SSD FTL > point of view and perhaps not being as useful as we might to virtually > provisioned LUNs ... so you could mention to the other vendors that they > might have an interest in coming (and even possibly sponsoring). I thought we had agreed on a plan which satisfied the SSD and insane array vendors. That is that we would do no tracking of allocation units in the filesystem, but instead extend each trim out to cover the maximum possible size. I've confirmed with Intel's SSD people that this would cause them no harm at all (trimming already trimmed sectors won't even cause a slowdown). Whether the filesystem people have taken note of this, I have no idea. -- 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." -- 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
