On Mar 16, 2014, at 12:06 AM, Marc MERLIN <marc@xxxxxxxxxxx> wrote: > > Mmmh, so now I'm confused. > > See this: > > === START OF INFORMATION SECTION === > Device Model: INTEL SSDSC2BW180A3L > Serial Number: CVCV215200XU180EGN > LU WWN Device Id: 5 001517 bb28c5317 > Firmware Version: LE1i > User Capacity: 180,045,766,656 bytes [180 GB] > Sector Size: 512 bytes logical/physical > Rotation Rate: Solid State Device > Device is: Not in smartctl database [for details use: -P showall] > ATA Version is: ACS-2 (minor revision not indicated) > SATA Version is: SATA 3.0, 3.0 Gb/s (current: 3.0 Gb/s) > Local Time is: Sat Mar 15 15:49:06 2014 PDT > SMART support is: Available - device has SMART capability. > SMART support is: Enabled > > polgara:/usr/src# smartctl --identify /dev/sda | grep '^ 169' > 169 - 0x0001 Data Set Management support > 169 0 1 Trim bit in DATA SET MANAGEMENT command supported > > This is a super old SSD from 3 years ago. Clearly it can't support > synchronous dicard, right? No. The first signs I saw they were appearing in the wild was 3rd quarter 2013. I'm pretty sure SAS SSDs always have had a queued trim command. So in the workloads that demanded it and with a budget, this wouldn't have ever been a problem. > Yet, deleting a kernel tree also takes 1.5 seconds: > polgara:/usr/src# time rm -rf linux-3.14-rc5/ > real 0m1.441s > user 0m0.048s > sys 0m1.352s I don't know that this is a good test for two reasons. Does rm always call trim before the rm command completes? If trim is batched or delayed it could happen well after. Second, and more of a factor, the queue needs to have pending commands in them that an async trim command will have to wait for. The problem with non-queued trim is that it requires the queue to be empty. So you'd need a test or workload that causes that behavior to be a problem. And yet another factor with trim is that some SSDs immediately, aggressively start garbage collection and become slow to respond to anything. While others are smarter about doing this when the drive isn't as busy. Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
