linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chris Murphy <lists@colorremedies.com>
To: Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: Using BTRFS on SSD now ?
Date: Thu, 5 Jun 2014 12:13:37 -0600	[thread overview]
Message-ID: <FFF0E455-5905-47D4-A768-96CA2FEDF3B3@colorremedies.com> (raw)
In-Reply-To: <20140605145632.GD14713@merlins.org>


On Jun 5, 2014, at 8:56 AM, Marc MERLIN <marc@merlins.org> wrote:
> 
> compression: lzo, not zlib (zlib will slow down your SSD)

I've had mixed results, where benchmarking suggests lzo is faster, but then zlib actually feels faster. For sure forced zlib compression can be dreadful, but I kinda expect that and therefore don't use it. These days I'm not using any compression. I think a lot of the benchmarks suggesting one way or the other are just the wrong benchmarks to look at for this sort of thing, as they aren't testing the actual workloads that are typical.



> snapshots:
> http://marc.merlins.org/perso/btrfs/2014-03.html#Btrfs-Tips_-How-To-Setup-Netapp-Style-Snapshots
> auto-defrag: not really (read the archives)

Definitely there are some issues, it's probably why its not yet default. So I'd either not use it, or use it with the point of testing it to make it better.


> other options: leave default
> add -o discard to mount options

I disagree. The older the SSD almost certainly the worse its TRIM behavior will be, resulting in hangs possibly long hangs. There's a whole bunch of stuff written on lkml about non-queued TRIM ugliness. I think most users are better off issuing fstrim once a week until queued TRIM devices are in the wild and well tested.

The one case were file system discard is useful is not so much to inform the physical device but the next lower layer logical block device like md raid or LVM thinp so that the right unused blocks are freed up.

> 
> Do not use LVM, it's totally unnecessary and will slow you down. Dmcrypt is
> ok, however add discard to cryptsetup options too:
> root2		 /dev/sda2		/pwd		luks,discard

So again in this case I'd say don't use discard. Or at the very least, test it first. My SSD is reportedly not so bad in this regard, but I find even 2-3 second hang of *all* read/write events when deleting a bunch of files to be abhorrent. Some people report much, much longer delays as the SSD then also does immediate and aggressive GC.

I'd say, what slight additional wear occurs from not using discard, makes the SSD die sooner in order to justify getting a new SSD that maybe (?) doesn't have this problem anymore.

Chris Murphy


  parent reply	other threads:[~2014-06-05 18:13 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-05 13:30 Using BTRFS on SSD now ? Swâmi Petaramesh
2014-06-05 14:42 ` Russell Coker
2014-06-05 15:14   ` Swâmi Petaramesh
2014-06-05 16:26     ` Marc MERLIN
2014-06-05 18:34     ` Chris Murphy
2014-06-05 14:56 ` Marc MERLIN
2014-06-05 15:11   ` Roman Mamedov
2014-06-08 14:26     ` Pavel Volkov
2014-06-05 15:59   ` Christoph Anton Mitterer
2014-06-05 17:07     ` Swâmi Petaramesh
2014-06-05 18:13   ` Chris Murphy [this message]
2014-06-05 19:05     ` Marc MERLIN
2014-06-05 22:25       ` Duncan
2014-06-05 23:58         ` Martin K. Petersen
2014-06-06  0:24           ` Chris Murphy
2014-06-06  0:35           ` Duncan
2014-06-08 14:48           ` Pavel Volkov
2014-06-08 16:51             ` Martin K. Petersen
2014-06-05 21:15     ` Duncan
2014-06-05 16:17 ` Martin Steigerwald
2014-06-05 18:00 ` Chris Murphy

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=FFF0E455-5905-47D4-A768-96CA2FEDF3B3@colorremedies.com \
    --to=lists@colorremedies.com \
    --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).