linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Martin Steigerwald <Martin@lichtvoll.de>
To: "Swâmi Petaramesh" <swami@petaramesh.org>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Using BTRFS on SSD now ?
Date: Thu, 05 Jun 2014 18:17:54 +0200	[thread overview]
Message-ID: <3972210.UmLM5TcfW1@merkaba> (raw)
In-Reply-To: <2215647.hErg5R77lo@zafu>

Am Donnerstag, 5. Juni 2014, 15:30:26 schrieb Swâmi Petaramesh:
> Hi,
> 
> I just received a new laptop with a Micron 256GB SSD, and I plan to install 
> Fedora 20 onto it.
> 
> I'm considering either BTRFS or ext4 (over LUKS-encrypted LVM) for this 
> machine, but I'm afraid BTRFS might generate too much writes and shorten
> the  SSD lifespan... Or am I mistaken ?

Relax.

I don´t know why you come to the conclusion BTRFS would create more writes
than other filesystems, but here are facts:

BTRFS on Intel SSD 320, since about month or so as RAID 1 on Intel SSD 320
and Crucial m5 mSATA. BTRFS on Intel SSD 320 since I think a bit more than
three years for now.

SMART Attributes Data Structure revision number: 5
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  3 Spin_Up_Time            0x0020   100   100   000    Old_age   Offline      -       0
  4 Start_Stop_Count        0x0030   100   100   000    Old_age   Offline      -       0
  5 Reallocated_Sector_Ct   0x0032   100   100   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       10289
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       2797
170 Reserve_Block_Count     0x0033   100   100   010    Pre-fail  Always       -       0
171 Program_Fail_Count      0x0032   100   100   000    Old_age   Always       -       0
172 Erase_Fail_Count        0x0032   100   100   000    Old_age   Always       -       169
183 Runtime_Bad_Block       0x0030   100   100   000    Old_age   Offline      -       1
184 End-to-End_Error        0x0032   100   100   090    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       0
192 Unsafe_Shutdown_Count   0x0032   100   100   000    Old_age   Always       -       241
199 UDMA_CRC_Error_Count    0x0030   100   100   000    Old_age   Offline      -       0
225 Host_Writes_32MiB       0x0032   100   100   000    Old_age   Always       -       449085
226 Workld_Media_Wear_Indic 0x0032   100   100   000    Old_age   Always       -       2204365
227 Workld_Host_Reads_Perc  0x0032   100   100   000    Old_age   Always       -       49
228 Workload_Minutes        0x0032   100   100   000    Old_age   Always       -       13212562
232 Available_Reservd_Space 0x0033   100   100   010    Pre-fail  Always       -       0
233 Media_Wearout_Indicator 0x0032   099   099   000    Old_age   Always       -       0
241 Host_Writes_32MiB       0x0032   100   100   000    Old_age   Always       -       449085
242 Host_Reads_32MiB        0x0032   100   100   000    Old_age   Always       -       1144183


Media Wearout Indicator was 100 initially, now is 99. Thus the SSDs considers
itself to be basically new. Use search machine to find PDF of Intel about
that value.

And 449085 32 MiB Host Writes with KDE session, desktop search Nepomuk, now
Baloo, Akonadi setups with insanely sized mailbox and what not. Thats:

irb(main):027:0> 449085 * 32 / 1024.0 / 1024.0
=> 13.704986572265625

13,7 TiB. This Intel SSD is specced for a useful life of 5 years with 20 GB
host writes *each day*. Thats about 7 TiB per year, even if you use 1000 as
base here. 3 years * 7 TiB = 21 TiB.


So look at your SSD endurance specification and then just relax :)

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

  parent reply	other threads:[~2014-06-05 16:18 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-05 13:30 Using BTRFS on SSD now ? Swâmi Petaramesh
2014-06-05 14:42 ` Russell Coker
2014-06-05 15:14   ` Swâmi Petaramesh
2014-06-05 16:26     ` Marc MERLIN
2014-06-05 18:34     ` Chris Murphy
2014-06-05 14:56 ` Marc MERLIN
2014-06-05 15:11   ` Roman Mamedov
2014-06-08 14:26     ` Pavel Volkov
2014-06-05 15:59   ` Christoph Anton Mitterer
2014-06-05 17:07     ` Swâmi Petaramesh
2014-06-05 18:13   ` Chris Murphy
2014-06-05 19:05     ` Marc MERLIN
2014-06-05 22:25       ` Duncan
2014-06-05 23:58         ` Martin K. Petersen
2014-06-06  0:24           ` Chris Murphy
2014-06-06  0:35           ` Duncan
2014-06-08 14:48           ` Pavel Volkov
2014-06-08 16:51             ` Martin K. Petersen
2014-06-05 21:15     ` Duncan
2014-06-05 16:17 ` Martin Steigerwald [this message]
2014-06-05 18:00 ` Chris Murphy

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=3972210.UmLM5TcfW1@merkaba \
    --to=martin@lichtvoll.de \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=swami@petaramesh.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).