linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: Imran Geriskovan <imran.geriskovan@gmail.com>,
	linux-btrfs@vger.kernel.org
Subject: Re: Btrfs/SSD
Date: Mon, 17 Apr 2017 07:53:04 -0400	[thread overview]
Message-ID: <f5cb15a5-5566-b366-ebda-c3101fa96eec@gmail.com> (raw)
In-Reply-To: <CAK5rZE4ko_xFr_Zv=bmZ4tR9X59jXaqFnTv16_ynEO0+E5uzeg@mail.gmail.com>

On 2017-04-14 07:02, Imran Geriskovan wrote:
> Hi,
> Sometime ago we had some discussion about SSDs.
> Within the limits of unknown/undocumented device infos,
> we loosely had covered data retension capability/disk age/life time
> interrelations, (in?)effectiveness of btrfs dup on SSDs, etc..
>
> Now, as time passed and with some accumulated experience on SSDs
> I think we again can have a status check/update on them if you
> can share your experiences and best practices.
>
> So if you have something to share about SSDs (it may or may not be
> directly related with btrfs) I'm sure everybody here will be happy to
> hear it.

General info (not BTRFS specific):
* Based on SMART attributes and other factors, current life expectancy 
for light usage (normal desktop usage) appears to be somewhere around 
8-12 years depending on specifics of usage (assuming the same workload, 
F2FS is at the very top of the range, BTRFS and NILFS2 are on the upper 
end, XFS is roughly in the middle, ext4 and NTFS are on the low end 
(tested using Windows 7's NTFS driver), and FAT32 is an outlier at the 
bottom of the barrel).
* Queued DISCARD support is still missing in most consumer SATA SSD's, 
which in turn makes the trade-off on those between performance and 
lifetime much sharper.
* Modern (2015 and newer) SSD's seem to have better handling in the FTL 
for the journaling behavior of filesystems like ext4 and XFS.  I'm not 
sure if this is actually a result of the FTL being better, or some 
change in the hardware.
* In my personal experience, Intel, Samsung, and Crucial appear to be 
the best name brands (in relative order of quality).  I have personally 
had bad experiences with SanDisk and Kingston SSD's, but I don't have 
anything beyond circumstantial evidence indicating that it was anything 
but bad luck on both counts.

Regarding BTRFS specifically:
* Given my recently newfound understanding of what the 'ssd' mount 
option actually does, I'm inclined to recommend that people who are 
using high-end SSD's _NOT_ use it as it will heavily increase 
fragmentation and will likely have near zero impact on actual device 
lifetime (but may _hurt_ performance).  It will still probably help with 
mid and low-end SSD's.
* Files with NOCOW and filesystems with 'nodatacow' set will both hurt 
performance for BTRFS on SSD's, and appear to reduce the lifetime of the 
SSD.
* Compression should help performance and device lifetime most of the 
time, unless your CPU is fully utilized on a regular basis (in which 
case it will hurt performance, but still improve device lifetimes).

  reply	other threads:[~2017-04-17 11:53 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-14 11:02 Btrfs/SSD Imran Geriskovan
2017-04-17 11:53 ` Austin S. Hemmelgarn [this message]
2017-04-17 16:58   ` Btrfs/SSD Chris Murphy
2017-04-17 17:13     ` Btrfs/SSD Austin S. Hemmelgarn
2017-04-17 18:24       ` Btrfs/SSD Roman Mamedov
2017-04-17 19:22         ` Btrfs/SSD Imran Geriskovan
2017-04-17 22:55           ` Btrfs/SSD Hans van Kranenburg
2017-04-19 18:10             ` Btrfs/SSD Chris Murphy
2017-04-18 12:26           ` Btrfs/SSD Austin S. Hemmelgarn
2017-04-18  3:23         ` Btrfs/SSD Duncan
2017-04-18  4:58           ` Btrfs/SSD Roman Mamedov
2017-04-17 18:34       ` Btrfs/SSD Chris Murphy
2017-04-17 19:26         ` Btrfs/SSD Austin S. Hemmelgarn
2017-04-17 19:39           ` Btrfs/SSD Chris Murphy
2017-04-18 11:31             ` Btrfs/SSD Austin S. Hemmelgarn
2017-04-18 12:20               ` Btrfs/SSD Hugo Mills
2017-04-18 13:02   ` Btrfs/SSD Imran Geriskovan
2017-04-18 13:39     ` Btrfs/SSD Austin S. Hemmelgarn
2017-05-12 18:27     ` Btrfs/SSD Kai Krakow
2017-05-12 20:31       ` Btrfs/SSD Imran Geriskovan
2017-05-13  9:39       ` Btrfs/SSD Duncan
2017-05-13 11:15         ` Btrfs/SSD Janos Toth F.
2017-05-13 11:34         ` [OT] SSD performance patterns (was: Btrfs/SSD) Kai Krakow
2017-05-14 16:21         ` Btrfs/SSD Chris Murphy
2017-05-14 18:01           ` Btrfs/SSD Tomasz Kusmierz
2017-05-14 20:47             ` Btrfs/SSD (my -o ssd "summary") Hans van Kranenburg
2017-05-14 23:01             ` Btrfs/SSD Imran Geriskovan
2017-05-15  0:23               ` Btrfs/SSD Tomasz Kusmierz
2017-05-15  0:24               ` Btrfs/SSD Tomasz Kusmierz
2017-05-15 11:25                 ` Btrfs/SSD Imran Geriskovan
2017-05-15 11:46       ` Btrfs/SSD Austin S. Hemmelgarn
2017-05-15 19:22         ` Btrfs/SSD Kai Krakow
2017-05-12  4:51   ` Btrfs/SSD Duncan
2017-05-12 13:02     ` Btrfs/SSD Imran Geriskovan
2017-05-12 18:36       ` Btrfs/SSD Kai Krakow
2017-05-13  9:52         ` Btrfs/SSD Roman Mamedov
2017-05-13 10:47           ` Btrfs/SSD Kai Krakow
2017-05-15 12:03         ` Btrfs/SSD Austin S. Hemmelgarn
2017-05-15 13:09           ` Btrfs/SSD Tomasz Kusmierz
2017-05-15 19:12             ` Btrfs/SSD Kai Krakow
2017-05-16  4:48               ` Btrfs/SSD Duncan
2017-05-15 19:49           ` Btrfs/SSD Kai Krakow
2017-05-15 20:05             ` Btrfs/SSD Tomasz Torcz
2017-05-16  1:58               ` Btrfs/SSD Kai Krakow
2017-05-16 12:21                 ` Btrfs/SSD Tomasz Torcz
2017-05-16 12:35                   ` Btrfs/SSD Austin S. Hemmelgarn
2017-05-16 17:08                   ` Btrfs/SSD Kai Krakow
2017-05-16 11:43             ` Btrfs/SSD Austin S. Hemmelgarn
2017-05-14  8:46       ` Btrfs/SSD Duncan

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=f5cb15a5-5566-b366-ebda-c3101fa96eec@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=imran.geriskovan@gmail.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).