On Thu, Aug 19, 2010 at 11:48 AM, Martin K. Petersen
<martin.petersen@xxxxxxxxxx> wrote:
> ATA IDENTIFY DEVICE word 105 contains the number of 512-byte blocks of
> TRIM payload information the device can accept in one command. Use this
> value to enable payloads > 512 bytes.
>
> Signed-off-by: Martin K. Petersen <martin.petersen@xxxxxxxxxx>
> ---
> drivers/ata/libata-scsi.c | 7 ++++++-
> include/linux/ata.h | 9 +++++++++
> 2 files changed, 15 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
> index e280ae6..145f099 100644
> --- a/drivers/ata/libata-scsi.c
> +++ b/drivers/ata/libata-scsi.c
> @@ -2152,7 +2152,12 @@ static unsigned int ata_scsiop_inq_b0(struct ata_scsi_args *args, u8 *rbuf)
> * with the unmap bit set.
> */
> if (ata_id_has_trim(args->id)) {
> - put_unaligned_be32(65535 * 512 / 8, &rbuf[20]);
> + unsigned int blocks;
since blocks is nebulous, a comment would be nice, maybe:
unsigned int blocks; /* the ATA spec specifies
512-byte blocks for trim payload */
> +
> + /* Default to 1 if unspecified in word 105. Cap at 1 page. */
> + blocks = clamp(ata_id_trim_range_blocks(args->id), 1U, 8U);
Should there at least be a todo comment about raising that cap?
Or is there a fundamental reason for it. ie. I don't think the ATA
spec calls for it, so this is a kernel restriction I assume.
> +
> + put_unaligned_be32(65535 * 512 / 8 * blocks, &rbuf[20]);
Is this patch actually enabling the block layer to initiate ATA
multi-sector trim payloads, or is this only allowing the max payloads
sectors to be queried?
Are there plans (or existing code) to accumulate trim ranges in the
block layer and create trim commands with multiple sectors?
AFAIK, the only block layer feature exported to the file system layer
only accepts one range.
I'd like to see multiple trim ranges accumulated either by the
filesystem prior to calling into the block layer, of have the block
layer accumulate them. (I suspect its easier for the filesystem to do
it via the proposed fitrim() ioctl that is on the ext4 list recently.
ie. the current proposed fitrim() ioctl calls into the block layer for
each trim range, but it could easily have the ability to accumulate a
vector of trim ranges and call the block layer only once per trim
vector if the block layer had a interface for that.
Greg
--
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
