All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.