[Top] [All Lists]

Re: TRIM details

To: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
Subject: Re: TRIM details
From: Phil Karn <karn@xxxxxxxx>
Date: Fri, 07 Jan 2011 15:43:22 -0800
Cc: Matthias Schniedermeyer <ms@xxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <yq1ei8oodz2.fsf@xxxxxxxxxxxxxxxxxx>
References: <4D2686ED.7000304@xxxxxxxxxxxx> <20110107091120.GA6634@xxxxxxx> <4D271F8D.3030404@xxxxxxxx> <yq1ei8oodz2.fsf@xxxxxxxxxxxxxxxxxx>
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv: Gecko/20101207 Thunderbird/3.1.7
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.


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