9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: digbyt42@gmail.com (Digby R.S. Tarvin)
Subject: [9fans] Is fossil/venti file system a good choice for SSD?
Date: Sat,  3 Feb 2018 18:49:50 +0000	[thread overview]
Message-ID: <CACo5X5j1v9cAoxqxEG=1OyfiRdUYFjpfN5dh9F+NK0=WGPAKSw@mail.gmail.com> (raw)
In-Reply-To: <CAFSF3XPLw3RgfTdHXpJJft3=DxsAq=nj1fFLabLik49UVKFi0g@mail.gmail.com>

My experience of running normal (read mostly) Linux filesystems on solid
state media is that SSD is more robust but far less reliable than rotating
media.

MTBF for rotating media for me has been around 10 years. MTBF for SSD has
been about 2. And the SSD always seems to fail catastrophically - appearing
to work fine one day, then after an inexplicable crash, half the media is
unreadable. I assume this is something to do with the wear leveling, which
successfully gets most of the blocks to wear out at the same time with no
warning. If I reformat and reload the SSD to correct all the mysterious
corruptions, it last a few weeks, then does the same thing again.

I have had servers running of solid state media continuously since about
2003. Using PATA to CF adapters initially, currently uSD in raspberry pi
etc, and 2.5" SATA SSD drives. I used to use mostly SCSI rotating media, so
my reliability may have been better than cheaper PC drives. I had quite a
few (probably 90%) of the 1GB Wren 7 drives retired after 10-15 years of
running 24/7 under very heavy load (in an on-air broadcast system) with no
signs of trouble. The 2.5" SATA form factor SSD's seem to last better -
perhaps indicating that the advertised capacity is a smaller proportion of
overall capacity available to level the wear over..

I don't have a large number of servers, so not really a big enough sample
to draw definite conclusions from, but enough to make me wary of relying
too much on SSD's as a panacea.

My current server configuration is a uSD system drive, with a much larger
rotating disk that spins down when not in use (generally only gets used
when a user is logged in), and an up to date backup of everything on the
uSD is kept on the rotating media. I am not keen on having SSD as a swap
device, unless you have multiple SSD's, in which case you just treat the
swap/tmp media as disposable. If I am short of ram (like on a raspberry
pi), I would prefer to have an external ram drive for swapping.

I have had the rotating media fail once in this configuration - quite
recently. 1TB 5.25", so quite a few years old.  It went through a couple of
months of taking too long to spin up when accessed after a spin down,
requiring a manual unmount to get the system to recognize it again. Then
eventually wouldn't spin up at all. The interesting thing (for me) was that
the SMART data from the drive gave it an all clear right to the end. But
unlike the SSDs, there was plenty of behavioural warning to remind me to
have the backups up to date and a spare at the ready...

So bottom line, in my experience, SSDs are great for read access time, low
power, low noise, and robustness. But they are not good for for
reliability, capacity or usage which is not read-mostly. (and RAID usage is
no substitute for backups - but that is another story)

DigbyT.

On 3 February 2018 at 16:53, hiro <23hiro at gmail.com> wrote:

> not so sure about mtbf. but it's too early to tell.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.9fans.net/private/9fans/attachments/20180203/39cdbedb/attachment.html>


  reply	other threads:[~2018-02-03 18:49 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-03  9:39 lchg
2018-02-03 10:54 ` Ethan Grammatikidis
2018-02-03 12:45 ` Steve Simon
2018-02-03 13:25   ` hiro
2018-02-03 14:53     ` Steve Simon
2018-02-03 16:53       ` hiro
2018-02-03 18:49         ` Digby R.S. Tarvin [this message]
2018-02-03 20:10           ` Bakul Shah
2018-02-03 21:46             ` Digby R.S. Tarvin
2018-02-03 23:46               ` Bakul Shah
2018-02-04  9:45                 ` [9fans] RasPi why? Ethan Grammatikidis
2018-02-04 15:05                   ` Rui Carmo
2018-02-04 16:36                   ` Steve Simon
2018-02-04 21:00                   ` Lyndon Nerenberg
2018-02-04 21:55                   ` Bakul Shah
2018-02-04 22:23                     ` hiro
2018-02-04 23:46                   ` Skip Tavakkolian
2018-02-04 23:52                     ` Lyndon Nerenberg
2018-02-05  9:22                     ` hiro
2018-02-05  9:27                       ` Rui Carmo
2018-02-05  9:48                         ` hiro
2018-02-05  9:49                           ` hiro
2018-02-04 10:02                 ` [9fans] Is fossil/venti file system a good choice for SSD? hiro
2018-02-04 23:46                   ` Bakul Shah
2018-02-05  8:50                     ` hiro
2018-02-04  9:52               ` hiro
2018-02-04 16:15                 ` Digby R.S. Tarvin
2018-02-04 21:46                   ` hiro
2018-02-04 22:47                     ` Digby R.S. Tarvin
2018-02-05  9:54                       ` hiro
2018-02-04  9:49           ` hiro
2018-02-04 22:22 ` Ole-Hjalmar Kristensen

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='CACo5X5j1v9cAoxqxEG=1OyfiRdUYFjpfN5dh9F+NK0=WGPAKSw@mail.gmail.com' \
    --to=digbyt42@gmail.com \
    /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).