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: 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).