linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: Recommended settings for SSD
Date: Sat, 25 May 2013 03:58:12 +0000 (UTC)	[thread overview]
Message-ID: <pan$1197$73f28aeb$cb95553f$36bb7307@cox.net> (raw)
In-Reply-To: CAAeznTo1uiZMgedoWfE-E0v=2vTWVkV0_k-9_+vVZ6YMFfjdRg@mail.gmail.com

Leonidas Spyropoulos posted on Fri, 24 May 2013 23:38:17 +0100 as
excerpted:

> On 24 May 2013 21:07, "cwillu" <cwillu@cwillu.com> wrote:
>>
>> No need to specify ssd, it's automatically detected.
> I'm not so sure it did detected. When I manually set it I saw
> significant improvement.

Without going back to check the wiki, IIRC it was there that the /sys 
paths it checks for that detection are listed.  Those paths are then 
based on what the drive itself claims.  If it claims to be rotating 
storage...

It may also depend on the kernel version, etc, as I'm not sure when that 
auto-detection was added (tho for all I know it has been there awhile).

I do know my new SSDs (Corsair Neutrons, 256GB) are detected here, and 
the ssd mount option is thus not needed.  However, I'm running current 
v3.10-rcX-git kernels, tho I'm a few days behind ATM as I'm still working 
on switching over to the SSDs ATM and am having to do some reconfiguring 
to get there.

Btrfs still being marked for testing only and under heavy development, if 
people aren't at least running current Linus stable or better and don't 
have a specific bug as a reason not to, they're actually behind and are 
likely missing potentially critical patches.  That means most people 
trying to run btrfs on stock distro kernels will be behind...


Meanwhile, what about the discard option?  As I'm still setting up on the 
SSDs as well as btrfs here, I haven't had a chance to decide whether I 
want that, or would rather setup fstrim as a cron job, or what.  But 
that's the other big question for SSD.

Here, I'm actually partitioning for near 100% over-provisioning, (120-ish 
GiB of partitions on the 238GiB/256GB drives, so I suspect actually 
running with discard as a mount option won't be such a big deal and will 
likely only cut write performance as I head toward stable-state, since 
the drive should have plenty of trimmed space to work with in any case 
due to the over-provisioning.  But I suspect it could be of benefit to 
those much closer to 0% over-provisioning than to my near 100%.

-- 
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


  reply	other threads:[~2013-05-25  3:58 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-24 20:06 Recommended settings for SSD Leonidas Spyropoulos
2013-05-24 20:07 ` cwillu
2013-05-24 22:38   ` Leonidas Spyropoulos
2013-05-25  3:58     ` Duncan [this message]
2013-05-25  8:21       ` Leonidas Spyropoulos
2013-05-25 10:14         ` Russell Coker
2013-05-25 12:13       ` Martin Steigerwald
2013-05-25 13:30         ` Duncan
2013-05-25 22:29         ` Leonidas Spyropoulos
2013-05-25 22:33           ` Harald Glatt
2013-05-26 10:00             ` Leonidas Spyropoulos
2013-05-26 15:16               ` Harald Glatt
2013-05-26 17:06                 ` cwillu
2013-05-25 22:49           ` Martin Steigerwald
2013-05-25 22:46         ` Martin Steigerwald

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$1197$73f28aeb$cb95553f$36bb7307@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;
as well as URLs for NNTP newsgroup(s).