We are finally starting to see some real technological
breakthroughs in the area of mobile storage after a long period of stagnation.
2004 saw the rise of speedy 7200RPM hard drives while this year saw the
introduction of perpendicular
recording which allows data to be recorded in a smaller area. Just
yesterday, DailyTech reported on Seagate's hybrid solution
which pairs a traditional hard drive with perpendicular recording technology to
256MB of non-volatile flash for better performance, increased battery life and
faster booting in Windows
Vista.

Today, PQI is showing off new drives that mimic Samsung's 32GB Flash-SSD.
PQI, with the help of Samsung NAND flash memory chips, has new 64GB IDE and
64GB SATA 2.5"
storage solutions for mobile users. The drives, which are due for release in
August, are by nature more rugged, lighter, cooler and more efficient than
traditional hard drives with a spinning disc. And best of all, there are
absolutely no moving part so no more listening to your hard drive whir while
you’re typing away and no more clicking and thrashing as you open up Photoshop
or perform other disk-intensive operations.

Pricing has not been announced on the new 64GB IDE and SATA 2.5" drives, but rest assured
that the new drives will be many times more expensive than even the fastest 7200RPM hard
drives on the market today. As the market matures and more players enter
the fray, we are sure to see a steady fall in prices. In fact, Samsung predicts
that the global market for NAND flash based drives will increase from $540M USD in 2006 to over $4.5 billion USD in 2010. With growth like that,
there will always be a premium for NAND-based disks over traditional hard
drives, but the price differential should be much more manageable than it is
today.

Comments

Threshold

Username

Password

remember me

This article is over a month old, voting and posting comments is disabled

Ok Saratoga, since you didnt answer my request for a math explanation... (and I think I can understand why you didn't), then I'll do the numbers for you:

64 GB = 64 x 10^9 bytes. It is NOT 64 x 10^12 as you show in your calculation. You were wrong by a factor of 1000x

But unfortunately for our longevity analysis, 64 GB = 125 million sectors (if one sector = 512 bytes), and when we "write" to Flash, whether just one byte, or a whole sector of data, we write the sector. Just like HDD.

So 125 million is the number we should use to base our calculations. And 125 million / 55 (writes per second) / 60 (secs per min) / 60 (mins per hour) / 24 (hrs per day) = 26 days

Yes. That was 26 days. Not 36898 years.

Whether a flash memory "block" is 128 bytes or 256 bytes (and not as large as a HDD 512 bytes sector) is moot, since the "writes" I had monitored were actually often 8 sectors at a time, ie, each "write" was in fact 4096 bytes and therefore up to 32 "blocks".

Now this survival period of 26 days assumes an even distribution of writes over the disk. However, in practice, data covers large portions of the disk, and system files, registry hives, paging files are going to have to be "dynamically remapped" within the existing unused portion of the flash drive. So the fuller the disk, the quicker it will die.

Moreover, because on a system like XP, 2003, or Vista we use NTFS (and not FAT like most USB drives) we also suffer from NTFS "transaction" logging and last access time. These will cause additional writes to "directory" sectors, MFT Zone, etc. etc.

Basically, for any demanding application running on Windows based boot drive, I cannot see how the flash disk will survive.

So therefore enthusiasts CANNOT use these drives for ultra-speed laptops. I can only see them being used as "damage proof" data drives, mobile devices, high G or "knock" environments, demanding low power or low noise situations, and other specialty circumstances.

****

I genuinely welcome a challenge, or correction, to my analysis and observations. But lets base them on facts and correct math! Thank you!

64gb. Say you have 30gb free. So, 30x10^9 bytes. Say you are saturating a SATA1 cable (re-writing the same data over and over, but such that it will actually write to the disk, and not fill it), so 150mb/sec or 150x10^6 bytes written/sec. It will take 200 sec to write over every empty byte on the drive (30gb).
Not that long, but here's the trick. Even if the flash memory is only rated for 300k writes, it will take 60,000,000 sec or 694.4 days to use up the rated writes writes on the drive. This assumes a good leveling algorithm, and it doesn't relocate any of the static data.

At 1x10^6 write operations, now you have 2314.8 days to burn out the drive. I don't know about you, but I find it unlikely I'm going to write flood a SATA drive for over 6 years continuously...

Hi rainman. Thanks for the back-of-the-envelope. A different (and simple = elegant) approach.

And based on the way you set up the calculation, the results seem correct.

Problem is that we need to consider NOT linear writes, one byte at a time, systematically going through the disk, efficiently, sector by sector... but the following issue:

1./ Every "write" to the flash disk will reduce the lifecycle of THE WHOLE "BLOCK" by -1
2./ A block on a flash disk is 128, 256, or 512 bytes depending on how it was built.
3./ An NTFS sector is therefore (typically) 4, 2 or 1 "block"
4./ When reading/writing NTFS under typical Windows activities, usually, 1, 2, 4, 8, or 16 sectors are read/written at once. Other permutations are possible.

If data is nicely cached before being written (as suggested in earlier posts) e.g. the comment "stick in more memory to your laptop"... then as long as WRITE instructions are being cached, then this will help improve the lifetime.

HOWEVER, in data critical situations, write caching is not recommended. Caching writes is not what this type of "industrial hard core" memory is all about. It's about creating fail-safe, knock proof, power outage protected, enviroments. etc. etc.

AND WORSE. Since this is to replace an OS HDD, we are taking NTFS, and not FAT. That means every read is followed at some point by a write, due to the file stamping "last access time date".

So, if in your example, we were taking about read/write random access database, with, for whatever reasons, limited write-cache, then you need to divide your numbers by at least the block/sector size which is usually 128, 256 or 512 bytes.

lemonadesoda, your calculations make much less sense than rainman's. You failed to address the the idea that _each and every_ block on the disk is somehow touched by a write operation _55 times per second_. That is simply untrue, not to mention impossible (given that these things write at perhaps 20MB/sec, significantly less than the 150MB/sec of SATA 1).

This discourse would be useful if you seemed interested in finding the truth (which is as you said probably somewhere between the two extremes), but you seem much too inclined to reject anything that doesn't give a short-life estimate. Reasonable estimates suggest that there will be absolutely no problems within 10 or 15 years under normal usage patterns... I would like to know if any enthusiast has kept an OS and applications drive for that long (I've had a 36GB Raptor for not quite two years, and I'm already itching for these things to come out so I can replace it).

"Nowadays, security guys break the Mac every single day. Every single day, they come out with a total exploit, your machine can be taken over totally. I dare anybody to do that once a month on the Windows machine." -- Bill Gates