From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Merits of (auto)defrag on a mid-range ssd?
Date: Sat, 1 Jun 2013 03:30:14 +0000 (UTC) [thread overview]
Message-ID: <pan$9fb36$e8dd0021$54f93029$38e1c79f@cox.net> (raw)
Now that I'm switching from reiserfs on rust to btrfs on ssd, I'm
wondering about the autodefrag mount option.
The ssds are mid-range (Corsair Neutrons, NOT Neutron GTXs) so fragmented
access shouldn't be anything like the problem it is on spinning rust, but
I guess I should still keep fragmentation from getting /too/ far out of
hand, as AFAIK that increases IOPS and there's obviously a limit on
them. Additionally, I suppose the additional metadata bookkeeping could
eventually put further stress on btrfs in terms of concurrent ops, etc.
As I'm way overprovisioned (by about 100%, give or take depending on
whether I decide to lay down a swap/s2d partition or not, s2r works well
but s2d hasn't been due to video issues so I haven't been using that
anyway, and I'm running 16 gigs RAM w/ half of it empty even of cache
most of the time and power is quite stable here, so little real need for
s2d /or/ swap), ssd limited write-cycles shouldn't be a big deal either
way.
So for now I'm mounting with autodefrag, but honestly that's WAAYYY more
because I'm still used to thinking about spinning rust that I'm almost
afraid to turn it off, than it is about understanding the relative merits
either way.
So I'm asking, what are other people doing on SSD, why, and are there any
papers out there discussing the merits of defrag on mid-range SSDs, with
btrfs or in general?
SSDs are so new to me I'm having a hard time getting my head turned
around to think about them instead of spinning rust.
--
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-06-01 3:30 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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$9fb36$e8dd0021$54f93029$38e1c79f@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).