public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: discard synchronous on most SSDs?
Date: Fri, 14 Mar 2014 12:07:54 +0000 (UTC)	[thread overview]
Message-ID: <pan$667da$c4955705$c59674a0$a844850c@cox.net> (raw)
In-Reply-To: 20140314051750.GY6143@merlins.org

Marc MERLIN posted on Thu, 13 Mar 2014 22:17:50 -0700 as excerpted:

> On Thu, Mar 13, 2014 at 09:39:02PM -0600, Chris Murphy wrote:
>> 
>> On Mar 13, 2014, at 8:11 PM, Marc MERLIN <marc@merlins.org> wrote:
>> 
>> > On Sun, Mar 09, 2014 at 11:33:50AM +0000, Hugo Mills wrote:
>> >> discard is, except on the very latest hardware, a synchronous
>> >> command (it's a limitation of the SATA standard), and therefore
>> >> results in very very poor performance.
>> > 
>> > Interesting. How do I know if a given SSD will hang on discard?
>> > Is a Samsung EVO 840 1TB SSD latest hardware enough, or not? :)
>> 
>> smartctl -a or -x will tell you what SATA revision is in place. The
>> queued trim support is in SATA Rev 3.1. I'm not certain if this
>> requires only the drive to support that revision level, or both
>> controller and drive.
> 
> I'm not sure I'm seeing this, which field is that?

> ATA Version is:   8
> ATA Standard is:  ATA-8-ACS revision 4c

Your drive didn't report it, but here, I have SATA fields as well, in 
addition to the ATA fields:

Here's the fields from my Corsair Neutron SSDs:

ATA Version is:   ATA8-ACS (minor revision not indicated)
SATA Version is:  SATA 2.5, 6.0 Gb/s

Here's the fields from my Seagate 500-gig 2.5-inch spinning rust:

ATA Version is:   ATA8-ACS T13/1699-D revision 4
SATA Version is:  SATA 2.6, 3.0 Gb/s

(More about that below.)

Smartctl version here is 6.2 2013-07-26 r3841, according to the output. 
(I'm running gentoo/~amd64 FWIW so it's a local-build). You snipped that 
bit of your output so I can't compare.

But it may also depend on whether smartctl auto-detected and used the ATA 
or the SCSI (or something else) command set and how your devices are 
actually connected, plus BIOS settings, etc.  See the manpage 
documentation for the -d TYPE (--device=TYPE) option and the ATA/SCSI/SAT 
discussion rather further down the manpage for more.

Here I have direct SATA connections with the BIOS set to AHCI mode and am 
thus using the kernel's AHCI drivers, since that's the most common SATA 
chipset standard these days, thus increasing portability given my 
monolithic kernel build.

smartctl's -d test reports an original guess of scsi, changed to sat 
after detection.

Of course connection via USB bridge or the like complicates things 
considerably.


Meanwhile, SATA 2.5, 6 Gb/s on the SSDs, SATA 2.6, 3 Gb/s on the spinning 
rust?  WTF?  The SSDs have SATA 2.5 but 6 Gb/s while the spinning rust 
has a later 2.6 but only 3 Gb/s (tho of course on a mechanical drive the 
bus speed won't be the bottleneck)?  Now I'm confused.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


  parent reply	other threads:[~2014-03-14 12:08 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-09  7:48 Massive BTRFS performance degradation KC
2014-03-09  8:17 ` Swâmi Petaramesh
2014-03-09 10:01   ` Martin Steigerwald
2014-03-09 10:23     ` Swâmi Petaramesh
2014-03-09 11:33       ` Hugo Mills
2014-03-09 11:54         ` Martin Steigerwald
2014-03-09 12:10         ` Swâmi Petaramesh
2014-03-09 17:14           ` boris
2014-03-14  2:11         ` discard synchronous on most SSDs? Marc MERLIN
2014-03-14  3:39           ` Chris Murphy
2014-03-14  5:17             ` Marc MERLIN
2014-03-14  7:33               ` Chris Samuel
2014-03-14 19:26                 ` Marc MERLIN
2014-03-14 19:57                   ` Martin K. Petersen
2014-03-14 20:46                     ` Holger Hoffstätte
2014-03-15  4:21                       ` Marc MERLIN
2014-03-15  9:38                         ` Holger Hoffstätte
2014-03-15  5:25                     ` Chris Samuel
2014-03-15  6:48                       ` Chris Samuel
2014-03-15 11:26                         ` Duncan
2014-03-15 22:48                           ` Chris Samuel
2014-03-16  6:06                           ` Marc MERLIN
2014-03-16 17:09                             ` Chris Murphy
2014-03-16 16:22                       ` Martin K. Petersen
2014-03-16 17:50                         ` Marc MERLIN
2014-03-15  4:06                 ` Chris Samuel
2014-03-16 16:07                   ` Martin K. Petersen
2014-03-14 12:07               ` Duncan [this message]
2014-03-14 21:44               ` Chris Murphy
2014-03-14  7:27             ` Chris Samuel
2014-03-09 17:36   ` Massive BTRFS performance degradation Austin S Hemmelgarn
2014-03-09 18:55     ` Tobias Holst

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='pan$667da$c4955705$c59674a0$a844850c@cox.net' \
    --to=1i5t5.duncan@cox.net \
    --cc=linux-btrfs@vger.kernel.org \
    /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