On Thu, Apr 15, 2010 at 6:21 PM, Bill Weiler <weilerb@xxxxxxxxxxx> wrote: > Yes. > > Here is some additonal info: in libata-scsi.c > > > tf->protocol = ATA_PROT_DMA; > 2983 tf->hob_feature = 0; > 2984 tf->feature = ATA_DSM_TRIM; //0x01 > 2985 tf->hob_nsect = (size / 512) >> 8; > 2986 tf->nsect = size / 512; > 2987 tf->command = ATA_CMD_DSM; //0x06 > 2988 tf->flags |= ATA_TFLAG_ISADDR | ATA_TFLAG_DEVICE | ATA_TFLAG_LBA48 | > 2989 ATA_TFLAG_WRITE; > 2990 > > ________________________________________ > From: Simon Kitching [simon.kitching@xxxxxxxxxx] > Sent: Thursday, April 15, 2010 3:18 PM > To: Bill Weiler > Cc: kernelnewbie > Subject: Re: Researching ATA TRIM command > > On Thu, 2010-04-15 at 14:25 -0700, Bill Weiler wrote: >> All, >> I found the task file call in libata-scsi.c in kernel 2.6.33. >> >> TRIM seem to be a SCSI to ATA translation of "WRITE SAME 16". >> >> Under what conditions would "WRITE SAME 16" be called? >> >> (I am not as familiar with SCSI as I am with ATA). > > > Is this the TRIM operation you are asking about? > > http://en.wikipedia.org/wiki/TRIM So your question is when TRIM is invoked in the linux kernel? If so, When trim support was added about a year ago, they decided a generic phrase was needed that is neither ATA nor SCSI specific. They tend to us both "unmap" abd "discard". ext4 / xfs / fat now all have discard support, but at least with ext4 the way the implemented it is generating huge number of discard calls that hurt performance. Since the whole purpose of trim is to improve performance, that is not very acceptable. A couple patches were posted to the ext4 list a few days ago that attempt to improve the situation. http://lwn.net/Articles/383933/ is the intro post. The patches were posted shortly after that post. I suspect they are still not good enough in that it is still one trim command issued to the SSD per discard range. Mark Lord implemented a userspace based solution that grouped numerous discard ranges into a single trim command to the SSD. And in this thread: http://www.mentby.com/mark-lord/discard-support.html Pay particular attention to Mark Lord's posts. He's done the most benchmarking that I've seen. It concludes with a userspace solution being the best option. I'm not sure where it is all heading, because kernel implementations are still in place and as you see there is a new patch. Hope that helps Greg -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
