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
next prev parent 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).