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
next prev parent 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).