From: Matthias Schniedermeyer <ms@citd.de>
To: karn@ka9q.net
Cc: xfs@oss.sgi.com
Subject: Re: TRIM details
Date: Fri, 7 Jan 2011 10:11:20 +0100 [thread overview]
Message-ID: <20110107091120.GA6634@citd.de> (raw)
In-Reply-To: <4D2686ED.7000304@philkarn.net>
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.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2011-01-07 9:09 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-07 3:22 TRIM details Phil Karn
2011-01-07 4:35 ` Martin K. Petersen
2011-01-07 9:11 ` Matthias Schniedermeyer [this message]
2011-01-07 9:17 ` Matthias Schniedermeyer
2011-01-07 14:15 ` Phil Karn
2011-01-07 14:13 ` Phil Karn
2011-01-07 16:50 ` Martin K. Petersen
2011-01-07 23:43 ` Phil Karn
2011-01-07 14:21 ` Phil Karn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110107091120.GA6634@citd.de \
--to=ms@citd.de \
--cc=karn@ka9q.net \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox