jim owens wrote:
Theodore Tso wrote:
On Fri, Nov 07, 2008 at 01:09:48PM -0500, Ric Wheeler wrote:
I don't think that trim bugs should be that common - we just have to
be very careful never to send down a trim for any uncommitted block.
The trim code probably deserves a very aggressive unit test to make
sure it works correctly, but yeah, we should be able to control any
trim bugs.
Simple is always good, but I still think that the coalescing (even
basic coalescing) will be a critical performance feature.
Will we be able to query the device and find out its TRIM/UNMAP
alignment requirements? There is also a balanace between performance
(at least if the concern is sending too many separate TRIM commands)
and giving the SSD more flexibility in its wear-leveling allocation
decisions by sending TRIM commands sooner rather than later.
This is all good if the design is bounded by the requirements
of trim for flash devices. Because AFAIK the use of trim for
flash ssd is a performance optimization. The ssd won't loose
functionality if the trim is less than the chunk size. It may
run slower and wear out faster, but that is all.
If I understand correctly, with thin provisioning, unmapping
less than the chunk will not release that chunk for other use.
So you have lost the thin provision feature of the array.
The concern (Chris I think) and I have is that doing a design
to handle thin provision arrays *when chunk > fs_block_size*
that guarantees you will *always* release on chunk boundaries
is a lot more complicated.
To do that you kind of have to build a filesystem into the
block layer to persistently store "mapped/unmapped blocks
in chunk" and then do the "unmap-this-chunk" when a region
is all unmapped.
250 MB per 1TiB 512b sector disk for a simple 1-bit-per-sector
state. And that assumes you don't replicate it for safety.
That is what the array vendors are trying to avoid by pushing
it off to the OS.
Whoever supports thin provisioning better get their unmapping
correct because those big customers will be looking for who
to blame if they don't get all the features.
jim
I do think that what we have today is a reasonable start, especially if
we can do some coalescing of the unmap commands just like we do for
normal IO.
It does not have to be perfect, but it will work well for devices with a
reasonable chunk size.
A vendor could always supply a clean up script to run when we get too
out of sync between what the fs & storage device think is really
allocated. (Bringing back that wonderful model of windows defrag your
disk :-))
ric
--
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
