From: Martin Steigerwald <Martin@lichtvoll.de>
To: Imran Geriskovan <imran.geriskovan@gmail.com>
Cc: Kai Krakow <hurikhan77+btrfs@gmail.com>, linux-btrfs@vger.kernel.org
Subject: Re: Options for SSD - autodefrag etc?
Date: Sat, 25 Jan 2014 15:01:13 +0100 [thread overview]
Message-ID: <3664592.9YULOPb9vW@merkaba> (raw)
In-Reply-To: <CAK5rZE6bF+z6Y9=X7SxtRPHE=1nNRPMmASC0VU8u90HQ_LbzVA@mail.gmail.com>
Am Samstag, 25. Januar 2014, 15:33:08 schrieb Imran Geriskovan:
> Every write on a SSD block reduces its data retension capability.
>
> No concrete figures but it is assumed to be
> - 10 years for new devices
> - 1 year at rated usage. (There are much lower figures around)
Where do you have these figures from?
For the Intel SSD 320 in this ThinkPad T520 I read about a minimal usable live
of 5 years with 20 GB host writes each day in the tech specs. Thats 7300 GB a
year or 7,3 TB. I assume metric system here.
According to smartctl it has written
241 Host_Writes_32MiB 0x0032 100 100 000 Old_age Always
- 360158
360158 * 32 MiB (hmmm, now according to smartctl output this is MiB) which
gives almost 11 TiB (10,99).
The SSD is over 2,5 years old. Thats less than 5 TiB a year.
So that would lay within the range you say. Although the Intel SSD 320 isn´t
basically a new device in my eyes.
Thats with KDE session with Akonadi and desktop search, sometimes even two KDE
sessions and a load of applications running at times.
Anyway that SSDs still thinks it is well *new*:
233 Media_Wearout_Indicator 0x0032 100 100 000 Old_age Always
- 0
Thats the same media wearout indicator (which takes into account the amount of
Erase cycles according to Intel docs) it had at the first day I used it.
So I am basically not concerned.
While autodefrag mal cause additional writes… that would not even be the main
reason for me not to use it at the moment. I am just not convinced that it
gives any noticable benefit. And given that… of course it doesn´t make sense to
me to have it cause additional writes to the SSD.
But I am not using it due to avoiding those additional writes in the first
place.
My most important recommendation regarding SSDs still is: Keep some space
free. Yeah, SSD manufacturers are doing this. But in another Intel SSD PDF I
saw some graphs that convinced me in an instant that leaving free about 20% is
a good idea. But heck, due to the current fill status of this SSD I do not even
adhere to my own recommendation at the moment.
Then a occasional fstrim, maybe mount with noatime (cause who cares about it
at all?)…
Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
next prev parent reply other threads:[~2014-01-25 14:01 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-24 18:55 Options for SSD - autodefrag etc? KC
2014-01-24 20:27 ` Kai Krakow
2014-01-25 5:09 ` Duncan
2014-01-25 13:33 ` Imran Geriskovan
2014-01-25 14:01 ` Martin Steigerwald [this message]
2014-01-26 17:18 ` Duncan
[not found] ` <KA9w1n01A0tVtje01A9yLn>
2014-01-28 11:41 ` Duncan
-- strict thread matches above, loose matches on Subject: below --
2014-01-23 22:23 KC
2014-01-24 6:54 ` Duncan
2014-01-25 12:54 ` Martin Steigerwald
2014-01-26 21:44 ` Duncan
2014-01-24 20:14 ` Kai Krakow
2014-01-25 13:11 ` Martin Steigerwald
2014-01-25 14:06 ` Kai Krakow
2014-01-25 16:19 ` 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=3664592.9YULOPb9vW@merkaba \
--to=martin@lichtvoll.de \
--cc=hurikhan77+btrfs@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).