1TB Flash in 3.5" size?

#11

Arno <me (AT) privacy (DOT) net> kenjka:

Quote:

My calculations say that 400GB SLC drive can last 150 years with 24/7/365
writes on it (SLC, 100.000 E/W cycles)...

Ok, say 400GB at 200MB/s. That gives 1.8 overwrites/h, i.e. about
55'000h, i.e. about 6.25 years. Sorry your math is off. And
the 6.25 years are with perfect wear leveling. Assuming my
experience of death after 3'500 cycles with 10'000 cycle MLC,
the disk could die as early as within 2 years.

Even 1'000'000 cycle MLC only gives you 20-60 years.

Why are you referring to SSD drive and sequential writes? The main reason
why SSD are used are their high IOPS values! OK, I am talking from the
storage vendor perspective, and not from the home-user perspective...

--
Na tepihu se ponekad trijezan Maricao sere. By runf

Damir Lukic, calypso (AT) _MAKNIOVO_fly (DOT) srk.fer.hr
http://inovator.blog.hr
http://calypso-innovations.blogspot.com/

#12

calypso (AT) fly (DOT) srk.fer.hr.invalid wrote:

Quote:

Arno <me (AT) privacy (DOT) net> kenjka:
My calculations say that 400GB SLC drive can last 150 years with 24/7/365
writes on it (SLC, 100.000 E/W cycles)...

Ok, say 400GB at 200MB/s. That gives 1.8 overwrites/h, i.e. about
55'000h, i.e. about 6.25 years. Sorry your math is off. And
the 6.25 years are with perfect wear leveling. Assuming my
experience of death after 3'500 cycles with 10'000 cycle MLC,
the disk could die as early as within 2 years.

Even 1'000'000 cycle MLC only gives you 20-60 years.

Quote:

Why are you referring to SSD drive and sequential writes? The main reason
why SSD are used are their high IOPS values! OK, I am talking from the
storage vendor perspective, and not from the home-user perspective...

I am talking sustained maximum write speed. Does not need to be
sequential, but it is the worst-case for the lifetime. Of course
a lower rate with small writes that still result in an effective
write rate (because of larger internal block size) of 200MB/s
also hits this worst case.

And while the high IOP is one desirable parameter, it is not
the only one. For example an SSD can well be used for an external
filesystem journal. This is a mostly write and mostly sequential
write operation. However when you recover the journal the IOPs
are the bottleneck. So you may want to put your journal on the
SSD to bring recovery speed down dramatically. Or rollback
speed if it is a database journal.

For a home-user, OTOH, you may actually hit your figure. But
home users do not have 24/7 anyways.

So while your 150 years figure is certainly good to boost
sales, it is unusable to evaluate practical endurance. For
that you need to look at the particular worst case.

And there is a second problem. On power-fail a SSD can
corrupt areas not written to because of large internal
block sizes. That means in high-reliability applications
you actually can only write it in a sequential fashion
and without filesystem as everything else is dangerous to
your data.

The short summary is that SSDs have write issues that
you need to understand in order to decide whether to
use them or not. They shine on read IOPs though.

Arno
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno (AT) wagner (DOT) name
GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

#13

Arno <me (AT) privacy (DOT) net> kenjka:

Quote:

Why are you referring to SSD drive and sequential writes? The main reason
why SSD are used are their high IOPS values! OK, I am talking from the
storage vendor perspective, and not from the home-user perspective...

I am talking sustained maximum write speed. Does not need to be
sequential, but it is the worst-case for the lifetime. Of course a lower
rate with small writes that still result in an effective write rate
(because of larger internal block size) of 200MB/s also hits this worst
case.

But SSD's in any serious enviroments are never used for sequential writes...
OLTP and similar enviroments need high IOPS, not MB/s... If you want MB/s,
go with a big bunch of SATA drives, and you'll get very cheap MB/s
performance...

Quote:

So while your 150 years figure is certainly good to boost sales, it is
unusable to evaluate practical endurance. For that you need to look at the
particular worst case.

200MB/s is sequential read performance, and who knows what block size were
used... I stay with the 150 years, cause it's my calculation for STEC
ZeusIOPS drive used in EMC storage systems... So, here's the calculation:

400 * 10^9 * 100000 / 4000 / 2000 / 365 / 24 / 3600

400GB drive (400 * 10^9 Bytes)
SLC technology (100.000 E/W cycles)
4000 (block size is 4kBytes)
2000 (average write IOPS)
365 (days per year)
24 (hours per day)
3600 (seconds per hour)

The result is 158 years...

Quote:

And there is a second problem. On power-fail a SSD can corrupt areas not
written to because of large internal block sizes. That means in
high-reliability applications you actually can only write it in a
sequential fashion and without filesystem as everything else is dangerous
to your data.

Nope... At least not with drives I was working with... They all have 64MB
cache that has battery backup... This can be a problem for SMB drives, but
not for enterprise...

Sorry, but I am all into enterprise, and have totally lost touch with
reality in the normal SMB market...

--
Boksaca svira nezdrav na maksimirskom stadionu cignu
maltretiru cijeli dan ? By runf

Damir Lukic, calypso (AT) _MAKNIOVO_fly (DOT) srk.fer.hr
http://inovator.blog.hr
http://calypso-innovations.blogspot.com/

#14

calypso (AT) fly (DOT) srk.fer.hr.invalid wrote:

Quote:

Arno <me (AT) privacy (DOT) net> kenjka:
Why are you referring to SSD drive and sequential writes? The main reason
why SSD are used are their high IOPS values! OK, I am talking from the
storage vendor perspective, and not from the home-user perspective...

I am talking sustained maximum write speed. Does not need to be
sequential, but it is the worst-case for the lifetime. Of course a lower
rate with small writes that still result in an effective write rate
(because of larger internal block size) of 200MB/s also hits this worst
case.

But SSD's in any serious enviroments are never used for sequential writes...
OLTP and similar enviroments need high IOPS, not MB/s... If you want MB/s,
go with a big bunch of SATA drives, and you'll get very cheap MB/s
performance...

You may have a combination of mostly sequential writes and under
some circumstances a lot of random reads. And yes, this can happen
in a serious environment as well although it requires a bit more
of a specual scenario.

Quote:

So while your 150 years figure is certainly good to boost sales, it is
unusable to evaluate practical endurance. For that you need to look at the
particular worst case.

200MB/s is sequential read performance, and who knows what block size were
used... I stay with the 150 years, cause it's my calculation for STEC
ZeusIOPS drive used in EMC storage systems... So, here's the calculation:

400 * 10^9 * 100000 / 4000 / 2000 / 365 / 24 / 3600

400GB drive (400 * 10^9 Bytes)
SLC technology (100.000 E/W cycles)
4000 (block size is 4kBytes)
2000 (average write IOPS)
365 (days per year)
24 (hours per day)
3600 (seconds per hour)

The result is 158 years...

Ah, you assume writes fall into one block of 4kB and the disk
block size is 4kB. Then you have a write speed of 8MB/s and yes,
your number fits. I expect these are a bit more expensive ;-)

However mass-market SSDs have 128kB blocks or even larger
(not exposed to the OS). There you get much lower numbers.
An affordable SSD with 4kB block size would be nice in fact,
due to much better small write performance.

Quote:

And there is a second problem. On power-fail a SSD can corrupt areas not
written to because of large internal block sizes. That means in
high-reliability applications you actually can only write it in a
sequential fashion and without filesystem as everything else is dangerous
to your data.

Nope... At least not with drives I was working with... They all have 64MB
cache that has battery backup... This can be a problem for SMB drives, but
not for enterprise...

Well, if you have RAM fronted SSD, you are in a different class anyways.
I remember that some Linux Filesystem people are starting to worry
about this, because it can kill journalling. There are some ways
around the problem, but only if the SSD exposes the block size.
Or if you have enough money for the expensive stuff ;-)

Quote:

Sorry, but I am all into enterprise, and have totally lost touch with
reality in the normal SMB market...

No problem. When you can really throw money at the problem, the
solutions look a bit different. Mass market can give you similar
performance and reliability a lot cheaper, but you have to go
some extra steps and really need to know what you are doing.

Arno
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno (AT) wagner (DOT) name
GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

#15

Arno <me (AT) privacy (DOT) net> kenjka:

Quote:

400 * 10^9 * 100000 / 4000 / 2000 / 365 / 24 / 3600

400GB drive (400 * 10^9 Bytes)
SLC technology (100.000 E/W cycles)
4000 (block size is 4kBytes)
2000 (average write IOPS)
365 (days per year)
24 (hours per day)
3600 (seconds per hour)

The result is 158 years...

Ah, you assume writes fall into one block of 4kB and the disk block size
is 4kB. Then you have a write speed of 8MB/s and yes, your number fits. I
expect these are a bit more expensive ;-)

Nonono...

There are few applications that has their block sizes with
which they deal... I believe Exchange uses 4kb block size, Oracle uses 8kb
and SQL uses 16k by default... I could be wrong here, it was a long time I
last checked this...

Anyway, storage systems write to cache, and cache flushes from time to time,
so there is no 24/7/365 in wildest dreams...

BTW., these drives are capable of 32-64 parallel IO operations...

Quote:

Nope... At least not with drives I was working with... They all have 64MB
cache that has battery backup... This can be a problem for SMB drives, but
not for enterprise...

Well, if you have RAM fronted SSD, you are in a different class anyways. I
remember that some Linux Filesystem people are starting to worry about
this, because it can kill journalling. There are some ways around the
problem, but only if the SSD exposes the block size. Or if you have
enough money for the expensive stuff ;-)

Nice to know this! Thanks!

Will investigate it a bit further...

Quote:

Sorry, but I am all into enterprise, and have totally lost touch with
reality in the normal SMB market...

No problem. When you can really throw money at the problem, the solutions
look a bit different. Mass market can give you similar performance and
reliability a lot cheaper, but you have to go some extra steps and really
need to know what you are doing.

Well, my clients are buying, and are very affraid of SSD drives because of
the problems visible in mass market... So I need to explain them that these
SSD drives used in high-end equipment haven't got anything similar to mass
market SSD drives...

--
Indijanaca spava corav na rijeckom stadionu murjaku
komponiru za svaku Novu Godinu ? By runf

Damir Lukic, calypso (AT) _MAKNIOVO_fly (DOT) srk.fer.hr
http://inovator.blog.hr
http://calypso-innovations.blogspot.com/

#16

calypso (AT) fly (DOT) srk.fer.hr.invalid wrote:

Quote:

Arno <me (AT) privacy (DOT) net> kenjka:
[...]
No problem. When you can really throw money at the problem, the solutions
look a bit different. Mass market can give you similar performance and
reliability a lot cheaper, but you have to go some extra steps and really
need to know what you are doing.

Well, my clients are buying, and are very affraid of SSD drives because of
the problems visible in mass market... So I need to explain them that these
SSD drives used in high-end equipment haven't got anything similar to mass
market SSD drives...

Ah, I see your problem. And it explains your stance, which I
think is justified on the equipment you are selling. If anybody
ever asks you about consumer-grade SSDs, give them my figures ;-)

Well, as I do understand the technology, I typically go for
mass-market, but my main application for large disk storage
so far was research data which was backed up on an enterprise
class tape library as well, so not really critical.

Arno
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno (AT) wagner (DOT) name
GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

#17

Arno <me (AT) privacy (DOT) net> kenjka:

Quote:

Well, my clients are buying, and are very affraid of SSD drives because of
the problems visible in mass market... So I need to explain them that these
SSD drives used in high-end equipment haven't got anything similar to mass
market SSD drives...

Ah, I see your problem. And it explains your stance, which I think is
justified on the equipment you are selling. If anybody ever asks you about
consumer-grade SSDs, give them my figures ;-)

Deal...

BTW., I am working as a presales engineer for EMC, VMware and Symantec...

Quote:

Well, as I do understand the technology, I typically go for mass-market,
but my main application for large disk storage so far was research data
which was backed up on an enterprise class tape library as well, so not
really critical.

Huh, tape libraries are good for smaller backup enviroments, but for big
customers, disklibraries (virtual tape libraries) are much better
solution...

--
"Ogadjens li Kinezo zigoshe ?" upita kreker trci dzusog prdija.
"Ne znam ja nista !" rece curicaa dira "Ja samo paso likuje imbecilanm !" By runf

Damir Lukic, calypso (AT) _MAKNIOVO_fly (DOT) srk.fer.hr
http://inovator.blog.hr
http://calypso-innovations.blogspot.com/

#18

Quote:

Does anyone yet make a TB Flash memory in a 3.5" drive physical format. If
so, could you pass on a reference? The interface would need to support
about at a 400MB/s sustained rate. I can work with any interface such as
Fiber Channel or whatever .

$3,799 at newegg for SATA (claimed 260 MB/s read and write):
http://www.newegg.com/Product/Produc...82E16820227502

$3,799 at newegg for PCI express (claimed 600 MB/s write and
870 MB/s read ):
http://www.newegg.com/Product/Produc...82E16820227500

Lynn

#19

"David Brown" <david.brown (AT) hesbynett (DOT) removethisbit.no> wrote

Quote:

Arno wrote:
trs80 <trs80 (AT) yahoo (DOT) com> wrote:
Does anyone yet make a TB Flash memory in a 3.5" drive physical format.
If so, could you pass on a reference? The interface would need to
support about at a 400MB/s sustained rate. I can work with any
interface such as Fiber Channel or whatever .
thanks for any tips

Nobody does and nobody gets that rate, not even for large accesses.
Although some manufacturers have SATA3 drives
planned with internal excessive multi channel architectures.
For small accesses FLASH can be significantly slower than
disks. For what you want, you may want to look at a traditional RAM
fronted disk. Will be expensive though and definitely
not available in 3.5". Alternatively you could build a RAID0 with a
really fast controller and FLASH disks. Arno

There are a number of very fast drives available, but the cost is
significant - a raid would be much more cost-effective. The biggest
single drive I found in a quick check was:

http://www.plianttechnology.com/lightning_ls.php

That's 300 GB in 3.5" SAS, rated at 525/340 MB/s.

Of course, for the fastest devices you use a PCI Express card with RAM
rather than flash...

The fastest and largest I have seen is the 1TB OCZ PCIe
SSD with read and write rates of 870MB/s and 780MB/s.
The part number is OCZSSDPCIE-ZDM841T, and the
price is a mere $4k approx.

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

1TB Flash in 3.5" size?

PC Storage Devices Hard drives & other PC storage devices discussions (comp.sys.ibm.pc.hardware.storage)

Re: 1TB Flash in 3.5" size? - 02-09-2010 , 06:00 AM

Re: 1TB Flash in 3.5" size? - 02-09-2010 , 07:43 AM

Re: 1TB Flash in 3.5" size? - 02-09-2010 , 10:23 AM

Re: 1TB Flash in 3.5" size? - 02-09-2010 , 04:06 PM

Re: 1TB Flash in 3.5" size? - 02-09-2010 , 06:35 PM

Re: 1TB Flash in 3.5" size? - 02-09-2010 , 07:03 PM

Re: 1TB Flash in 3.5" size? - 02-09-2010 , 09:17 PM

Re: 1TB Flash in 3.5" size? - 02-10-2010 , 06:43 PM

Re: 1TB Flash in 3.5" size? - 02-19-2010 , 11:01 PM