Ric Wheeler wrote:
After talking to some vendors, one issue that came up is that the arrays
all have a different size that is used internally to track the SCSI
equivalent of TRIM commands (POKE/unmap).
What they would like is for us to coalesce these commands into aligned
multiples of these chunks. If not, the target device will most likely
ignore the bits at the beginning and end (and all small requests).
I have been thinking about whether or not we can (and should) do
anything more than our current best effort to send down large chunks
(note that the "chunk" size can range from reasonable sizes like 8KB or
so up to close to 1MB!).
The rational way to do this is to admit TRIM is only a feature
for filesystems that can set their allocation block size to
aligned multiples of the device "trim chunk size".
And the vendors need to provide the device trim chunk size in
a standard way (like scsi geometry) to the filesystem.
Devices with a trim chunk size of 512 bytes would work with
all filesystems. Devices with larger trim chunk sizes would
only receive trim commands from filesystems that can do large
allocation blocks (such as btrfs).
One suggestion is that a modified defrag sweep could be used
periodically to update the device (a proposal I am not keen on).
I don't like it either. But nothing prevents an array vendor
from building and shipping a tool to do this to fix their
big 1MB trim with small blocking filesystems.
jim
--
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
