From: Martin Steigerwald <martin@lichtvoll.de>
To: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
Cc: Roman Mamedov <rm@romanrm.net>, linux-btrfs@vger.kernel.org
Subject: Re: Experiences on BTRFS Dual SSD RAID 1 with outage of one SSD
Date: Fri, 17 Aug 2018 23:16:24 +0200 [thread overview]
Message-ID: <1816762.xWVpkm38nr@merkaba> (raw)
In-Reply-To: <94de7bd8-1b35-ecbb-566a-86b5c9de06fc@gmail.com>
Austin S. Hemmelgarn - 17.08.18, 15:01:
> On 2018-08-17 08:50, Roman Mamedov wrote:
> > On Fri, 17 Aug 2018 14:28:25 +0200
> >
> > Martin Steigerwald <martin@lichtvoll.de> wrote:
> >>> First off, keep in mind that the SSD firmware doing compression
> >>> only
> >>> really helps with wear-leveling. Doing it in the filesystem will
> >>> help not only with that, but will also give you more space to
> >>> work with.>>
> >> While also reducing the ability of the SSD to wear-level. The more
> >> data I fit on the SSD, the less it can wear-level. And the better
> >> I compress that data, the less it can wear-level.
> >
> > Do not consider SSD "compression" as a factor in any of your
> > calculations or planning. Modern controllers do not do it anymore,
> > the last ones that did are SandForce, and that's 2010 era stuff.
> > You can check for yourself by comparing write speeds of
> > compressible vs incompressible data, it should be the same. At
> > most, the modern ones know to recognize a stream of binary zeroes
> > and have a special case for that.
>
> All that testing write speeds forz compressible versus incompressible
> data tells you is if the SSD is doing real-time compression of data,
> not if they are doing any compression at all.. Also, this test only
> works if you turn the write-cache on the device off.
As the data still needs to be transferred to the SSD at least when the
SATA connection is maxed out I bet you won´t see any difference in write
speed whether the SSD compresses in real time or not.
> Besides, you can't prove 100% for certain that any manufacturer who
> does not sell their controller chips isn't doing this, which means
> there are a few manufacturers that may still be doing it.
Who really knows what SSD controller manufacturers are doing? I have not
seen any Open Channel SSD stuff for laptops so far.
Thanks,
--
Martin
next prev parent reply other threads:[~2018-08-18 0:21 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-17 9:08 Experiences on BTRFS Dual SSD RAID 1 with outage of one SSD Martin Steigerwald
2018-08-17 11:58 ` Austin S. Hemmelgarn
2018-08-17 12:28 ` Martin Steigerwald
2018-08-17 12:50 ` Roman Mamedov
2018-08-17 13:01 ` Austin S. Hemmelgarn
2018-08-17 21:16 ` Martin Steigerwald [this message]
2018-08-17 21:17 ` Martin Steigerwald
2018-08-18 7:12 ` Roman Mamedov
2018-08-18 8:47 ` Martin Steigerwald
2018-08-17 12:55 ` Austin S. Hemmelgarn
2018-08-17 21:26 ` Martin Steigerwald
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=1816762.xWVpkm38nr@merkaba \
--to=martin@lichtvoll.de \
--cc=ahferroin7@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=rm@romanrm.net \
/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).