xfs
[Top] [All Lists]

Re: TRIM details

To: karn@xxxxxxxx
Subject: Re: TRIM details
From: Matthias Schniedermeyer <ms@xxxxxxx>
Date: Fri, 7 Jan 2011 10:11:20 +0100
Cc: xfs@xxxxxxxxxxx
In-reply-to: <4D2686ED.7000304@xxxxxxxxxxxx>
References: <4D2686ED.7000304@xxxxxxxxxxxx>
User-agent: Mutt/1.5.19 (2009-01-05)
On 06.01.2011 19:22, Phil Karn wrote:
> Now that I've rebuilt my main Linux server, added a 120GB Intel SSD and
> converted all the file systems to XFS, I've gotten interested in the
> internals of both XFS and TRIM and how they work together (or will work
> together).
> 
> I'd like to know exactly how the drives implement TRIM but I've only
> found bits and pieces. Can anyone suggest a current and complete
> reference for the complete SATA command set that includes all the TRIM
> related stuff?
> 
> As I understand it, there's a SATA (and SCSI?) command that will
> repeatedly write a fixed block of data to some number of consecutive
> LBAs (WRITE SAME), and an "unmap" bit in the write command can be set to
> indicate that instead of actually writing the blocks, they can be marked
> for erasure and placed in the free pool.

I roughly know what happens in the SATA version.
The SATA command takes an sector-offset and a sector-count (up to 64k)

Spec is linked on the Wikipedia-page:
http://en.wikipedia.org/wiki/TRIM

> Is this the only way it can be done? It occurs to me that while an
> "unmap" bit should be quite fast, you don't absolutely *have* to have it.

"Quite fast" is something of an understatement.
The Intel SSD can TRIM the whole drive in a matter of seconds. I have 
tested that with hdparm, when i wrote me a simple disc imaging 
perl-script.

> Just have the drive interpret an ordinary write of all 0's to any LBA as
> an implicit "unmap" indication for that LBA. As long as the drive

The drive would have to look into each written sector in the off chance 
that it might be 0, that's a lot of electrons you have to burn for not 
much gain. And that's ignoring the performance side, doing such a check 
on each incoming write would be expensive at best.







Bis denn

-- 
Real Programmers consider "what you see is what you get" to be just as 
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated, 
cryptic, powerful, unforgiving, dangerous.


<Prev in Thread] Current Thread [Next in Thread>