From: Phil Karn <karn@ka9q.net>
To: Matthias Schniedermeyer <ms@citd.de>
Cc: xfs@oss.sgi.com
Subject: Re: TRIM details
Date: Fri, 07 Jan 2011 06:13:33 -0800 [thread overview]
Message-ID: <4D271F8D.3030404@ka9q.net> (raw)
In-Reply-To: <20110107091120.GA6634@citd.de>
On 1/7/11 1:11 AM, Matthias Schniedermeyer wrote:
> 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.
Oh, there's no question that an explicit TRIM command would be *far*
more efficient than an implicit TRIM that writes zeroes. If nothing
else, implicit TRIMming requires writing every single sector
individually, while the WRITE SAME command lets the host wipe up to
65,536 (I think) sectors with a single command.
But that's not my point. My point is that if the drive could recognize a
write of 0s to a sector as an implicit TRIM, then it would still be
possible to manually trim the drive without any support whatsoever from
the device driver or file system.
You could use a standard copy command, provided you have something like
/dev/zero, or you could write a simple application that wouldn't even
need root privileges (assuming it didn't need to get around any quotas
when creating the temporary file). And it would work for any file system
and any operating system while we're waiting for native TRIM support
(I'm still waiting for TRIM support for HFS+ in Mac OSX).
I don't think it would be that hard for the drive to recognize a write
of all zeroes. It already has to compute a set of Reed Solomon parity
symbols for every block written to the drive. That's quite a bit more
work than merely seeing if the block is all 0's.
You could even use the existing Reed-Solomon encoder to optimize the
process though I doubt it would really be necessary. The RS parities for
an all-0 data block are also all 0. If any of the parities are non zero,
then it can't be a block of 0's. If the parities are all zero, then
confirm in software that the data is all 0's; you'll have very few false
alarms.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2011-01-07 14:11 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
2011-01-07 9:17 ` Matthias Schniedermeyer
2011-01-07 14:15 ` Phil Karn
2011-01-07 14:13 ` Phil Karn [this message]
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=4D271F8D.3030404@ka9q.net \
--to=karn@ka9q.net \
--cc=ms@citd.de \
--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