On 07/11/2012 06:22 PM, Bar Ziony wrote: > If they are connected to a regular LSI controller they won't get TRIM > commands... How do you know they need TRIM? > We discussed this with LSI, their answer from generic support was basically nonsense, IMHO. This is a SAS Raid Controller, but after we run into the trim issue for the first time, we are using it in non-raid mode (flashed the corresponding fw). After we did so, we can trim with sg_unmap, but as we don't know which blocks are in use by the filesystem, we obviously have to trim the entire disk. And that means we have to recreate LVM + file-system every time trimming is required. Basic problem of those LSI controllers is that they don't announce their trimming capabilities via scsi VPD or Read Capacity (16), which the linux-scsi layer uses to query the disk for trim support. So the actual problem is the LSI SATA-to-SAS translation, which doesn't seem to let those important information through. I already thought about writing a kernel patch to set those values vai sysfs, but it probably will not get accepted, as setting the wrong values would result in data corruption after trimming... We are an HPC development group and our cluster is used sometimes for benchmarking. Once trimming is required, write performance of those disks goes down by about 50%. After manual sg_unmap performance is fine again... Cheers, Bernd -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
