Arch Linux

Description:
Since hdparm 9.29 (the first version after the patch), get_trim_dev_limit() has been added to the main hdparm program to determine the maximum TRIM ranges allowed in one ATA command.

As of hdparm 9.48, it is as the following:

static int
get_trim_dev_limit (void)
{
char model[41];

if (id[105] && id[105] != 0xffff)
return id[105];
extract_id_string(id + 27, 20, model);
if (0 == strcmp(model, "OCZ VERTEX-LE"))
return 8;
if (0 == strcmp(model, "OCZ-VERTEX"))
return 64;
return 1; /* all other drives, including Intel SSDs */
}

Note that the return number is not number of ranges, but the number of block of the payload. For example 1 block = 1 * 512 bytes / 8 bytes = 64 ranges, which is the limit of the kernel ATA TRIM:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/ata/libata-scsi.c?h=v4.4#n2215

So the patch should be gone since it is not necessary anymore. Not to mention that defaults to 65535 ranges is pretty much wrong/unsafe (even if we want to default to some possible maximum it should be 65536 ranges (1024-block payload).

The only "optimization" that the patch might bring is setting the ranges to 512 (8-block payload) for the Intel X18-M/X25-M G2 SSDs. It is only necessary if someone confirm that the series fail to report the limit in its ATA IDENTIFY DEVICE data (word 105). In that case he/she should simply report upstream. Not to mention that the default (64 ranges / 1-block payload) should still work on them (just not the fastest they can handle).


Additional info:
* package version(s)
* config and/or log files etc.


Steps to reproduce: