On Sat, 2009-02-07 at 15:50 -0700, Matthew Wilcox wrote: > 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. I don't think we got any input from array vendors, so it's rather hard to claim this. So part of this idea would be gathering the necessary inputs. > 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. It's one idea, but absent requirements from array vendors, we don't really know if it's the right one. 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