public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Phil Karn <karn@ka9q.net>
To: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: xfs@oss.sgi.com
Subject: Re: TRIM details
Date: Fri, 07 Jan 2011 15:43:22 -0800	[thread overview]
Message-ID: <4D27A51A.1090207@ka9q.net> (raw)
In-Reply-To: <yq1ei8oodz2.fsf@sermon.lab.mkp.net>

On 1/7/11 8:50 AM, Martin K. Petersen wrote:

> ATA does not have WRITE SAME. It's a SCSI command.

Ah. I keep thinking that the ATA commands are the same as SCSI commands
because Linux does a pretty good job of making ATA drives look as though
they're SCSI, but they're not a 1-1 mapping.

> But the fact remains that drives don't implement this. They do implement
> DSM TRIM. Even if the drives did support zero detection we'd have no way
> of getting the information to them short of sending a bazillion zeroes
> down the pipe.

I know.

> And why would the drive vendors add support for a
> crappier interface when DSM exists?

The *only* reason I suggest this is to make it possible to manually TRIM
a drive when the file system and/or device driver don't yet support the
explicit device-level TRIM command.

RAID subsystems are another obstacle to TRIM, but I don't quite see the
point in using RAID with SSDs, or especially why so many people seem to
want to do RAID-0 with SSDs. SSDs already implement something much like
RAID-0 internally, i.e., interleaving for speed, which is why the bigger
SSDs are generally faster than the smaller ones until the interface
saturates. At that point you're better off abandoning SATA and attaching
the SSD subsystem directly to the processor over a PCI-e path, as in the
OCX Revo drives.

The implicit TRIM-with-zeroes feature I suggest wouldn't have to be in
every drive. You wouldn't have to use it even if it were there. And I
will certainly use your new XFS code as soon as it's stable enough to go
into the production kernel.

But the many concerned about the lack of TRIM support in their
proprietary, closed-source OS/FS of choice could select such a drive and
trim manually at the application layer until (or if) their vendor
finally gets around to supporting explicit device-level TRIM. OSX still
doesn't have it, which is surprising given how many SSDs Apple has sold
in MacBooks -- and how much they charge for them.

This is not something I'd expected to be of direct use by those who use
XFS. But you've obviously been thinking a lot about SSDs and TRIM in
general so I knew you'd have some useful comments on the idea. I really
ought to approach an SSD vendor with this idea, but I don't know anybody
who works for one. Thanks for your ideas.

Phil

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2011-01-07 23:41 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
2011-01-07 16:50     ` Martin K. Petersen
2011-01-07 23:43       ` Phil Karn [this message]
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=4D27A51A.1090207@ka9q.net \
    --to=karn@ka9q.net \
    --cc=martin.petersen@oracle.com \
    --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