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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.