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