9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: erik quanstrom <quanstro@quanstro.net>
To: 9fans@9fans.net
Subject: Re: [9fans] just an idea (Splashtop like)
Date: Sun,  2 Aug 2009 18:16:43 -0400	[thread overview]
Message-ID: <47ec4ee980481cba90cd8510f0f3f519@quanstro.net> (raw)
In-Reply-To: <509071940908021223j4ede8588s5ed1854aecebc5e9@mail.gmail.com>

> > assuming honest mtbf numbers, one would expect similar
> > ures for the same io workload on the same size data set
> > as mechanical disks.  since flash drives are much smaller,
> > there would obviously be fewer ures per drive.  but needing
> > 10x more drives, the mtbf would be worse per byte of storage
> > than enterprise sata drives.  so you'd see more overall failures.
>
> this depends on usage, obviously. i think it misses the point that
> there's plenty of applications where the smaller storage (assuming a
> single unit) is perfectly adequate. i swapped out the HD in my laptop
> for a SD drive: the reduction in size is entirely workable, and the
> other benefits make the trade a big win. there're plenty of
> applications where i need relatively little raw storage: laptops, boot
> media for network terminals, embedded things.
>
> for large-scale storage, your analysis is much more appropriate. my
> file server remains based on spinning magnetic disks, and i expect
> that's likely to be the case for a long time.

on the other hand, since the ure rate is the same for a
mechanical disk as for your flash drive, one can't claim that
it's "more reliable".  it will return an unreadable error just
as often.  limiting your dataset on a mechanical hard drive
would accomplish the same goal for less cash.  and the afr (dirty secret:
the mtbf number is actually the extrapolated afr^-1) is only
0.4% instead of 0.7%.  at that rate, something else is more
likey to eat your laptop (gartner sez 20%/year.  but that's for
the intel enterprise ssd, which costs more than most laptops.
this article claims that flash is currently less reliable
the old-fashoned disks:

http://www.pcworld.com/article/143558/laptop_flash_drives_hit_by_high_failure_rates.html

surprising, no?  there are still plenty of reasons to want an
ssd.  it just seems that reliablity isn't one of those reasons yet.

- erik



  reply	other threads:[~2009-08-02 22:16 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-31 17:50 David Leimbach
2009-08-01  1:56 ` J.R. Mauro
2009-08-01  3:12   ` ron minnich
2009-08-01 11:58     ` erik quanstrom
2009-08-01 14:51       ` tlaronde
2009-08-01 14:57         ` erik quanstrom
2009-08-01 15:49         ` ron minnich
2009-08-01 19:10           ` J.R. Mauro
2009-08-02 18:17             ` erik quanstrom
2009-08-02 19:23               ` Anthony Sorace
2009-08-02 22:16                 ` erik quanstrom [this message]
2009-08-03  0:23                   ` Devon H. O'Dell
2009-08-03  0:37                     ` erik quanstrom
2009-08-03  2:09               ` John DeGood
2009-08-03  4:38                 ` erik quanstrom
2009-08-03 13:54                   ` John DeGood
2009-08-08  4:46               ` Dave Eckhardt
2009-08-08 11:37                 ` erik quanstrom
2009-08-02  2:55   ` John DeGood
2009-08-02  3:16     ` J.R. Mauro

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=47ec4ee980481cba90cd8510f0f3f519@quanstro.net \
    --to=quanstro@quanstro.net \
    --cc=9fans@9fans.net \
    /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).