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. 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.
That should be helpful for the array people, but for some of them with
really large delete chuck sizes, they will still miss a lot since their
size is larger than the average file size :-) I guess that we could do
something to resync - Ted mentioned some ideas for ext4.
On another note, they are pondering either using write same with the
discard bit set or the unmap command. It would seem that for thin
provisioning alone, either would work.
ric
--
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
