Martin K. Petersen wrote:
"Ric" == Ric Wheeler <rwheeler@xxxxxxxxxx> writes:
Ric> After talking to some vendors, one issue that came up is that the
Ric> arrays all have a different size that is used internally to track
Ric> the SCSI equivalent of TRIM commands (POKE/unmap).
I haven't had time to completely digest the latest (Nov. 4th) UNMAP
proposal yet. However, I don't recall seeing any notion of blocks
bigger than the logical block length. And the command clearly takes
(a list of) <start LBA, number of blocks>.
There is a proposal to expose this internal device size in a standard
way, but it has not been finalized.
Ric> What they would like is for us to coalesce these commands into
Ric> aligned multiples of these chunks.
Ric> If not, the target device will most likely ignore the bits at the
Ric> beginning and end (and all small requests).
That really just sounds like a broken firmware implementation on their
end. If they can not UNMAP a single logical block then they are
clearly not within the spirit of the proposed standard. Their thin
provisioning is going to suck and customers will hopefully
complain/buy a competing product.
I tend to agree with this point of view, but unfortunately, I think that
all of the major arrays have this kind of limitation to one degree or
another. I suspect that this will be a big deal with high end customers.
Just not sure that we have any way to handle this better than what is in
already (best effort, maybe a post/defrag like user util that can be run
offline to clean up?)
ric
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
