Slashdot Mirror
SSD Won't Make Sense In Laptops For Two Years
kgagne writes "While solid state disk drives can vastly improve random read performance and are perfectly suited to most mobile devices, many operations are sequential in laptops and desktops and involve writes where SSDs most often lose to magnetic hard disk drives in performance. While introducing multi-channel flash memory controllers and interleaving the NAND flash chips increases performance, it will still be about two years before the cost versus benefit ratio will make sense to install SSD in your laptop or desktop PC, according to a Computerworld story. '"I think you need to get to 128GB for around $200, and that's going to happen around 2010. Also, the industry needs to effectively communicate why consumers or enterprise users should pay more for less storage," says Joseph Unsworth, an analyst at Gartner Inc.'"
Try 16GB SDHC, available now for $50, delivered.
One for the OS and apps, one for the data. Need more? Put the other ones in your pocket.
Help stamp out iliturcy.
Complexity, power, heat, and failure from kinetic shock. These are either reduced or zero with a flash device.
If you're looking for non-mobile, or a large storage application, then the disk makes sense.
There's a reason those new Dells which boast 19h of battery life have SSD's
No, the new Dells that are boasting that have a battery pack option that is the same size as the bottom of the laptop. Think of one of those laptop cooler pads except 15 pounds of battery instead of a couple of fans inside.
Isn't this highly dependent on the filesystem you use and its strategy for block allocation ?
Yes, but...
Wouldn't it be possible to design the block allocation algorithm to favour SSDs...
Well, fragmentation isn't the answer. That seems to be what you're suggesting...
See, fragmentation introduces problems of its own -- for example, simple overhead of block allocation. If you've got a bunch of blocks that are sequential -- say, block 123, 124, 125, 126, and 127 -- you can say that a file is in an extent, from block 123-127. If, however, your file is stored in blocks 123, 259, 312, 567, and 964, you're going to have to store all of those addresses -- which means you're spending 250% more disk space simply storing addresses.
Also, Flash is written to (and read from) in rather huge blocks -- so you want a file to at least be contiguous on that level.
No, I would say that the simple solution to Flash not appearing to perform as well (for sequential operations) is to defragment just as aggressively, and to increase readahead by a lot. Flash would work great for contiguous sequential reads, assuming that the filesystem (or block layer) are anticipating that you'll keep reading from the same file.
But first, you need the flash disk itself to support simultaneous reads, and probably some OS support as well.
And for what it's worth, Linux has filesystems which are optimized for raw Flash -- which handle things like wear-leveling on their own. CompactFlash, and the newer standards, provide an IDE-like interface, which does the wear-leveling in hardware -- in other words, they pretend to be a hard disk, mostly for the benefit of Windows.
So I predict two things: First, that Linux will solve this problem the "right way", given sufficiently low-level access. And second, that there will be a lot of hardware, firmware, and BIOS hacks to get around the fact that Windows isn't going to be changing its filesystem anytime soon.
Don't thank God, thank a doctor!
How many write cycles are your SSDs good for?
With wear leveling? More than a hard drive. Time to put that myth to rest. And no, I am not trolling.
Not true. SSDs are already faster in every aspect than magnetic drives. And the new intel ssd drive will totally offset this in favor of ssds. Even the price is no longer a big issue, 64GB SSD drives can be gotten for $270.
120mb/s sustained and sequential read and write. WD Velociraptor (the new 10k rpm drive) has that value much lower at 85mb/s sustained and 68mb/s sequential.
http://benchmarkreviews.com/index.php?option=com_content&task=view&id=149&Itemid=1&limit=1&limitstart=4
The Intel drive uses MLC and while its write speed might appear competitive, the relatively large block erase that happens with MLC will make this drive impractical for typical "system drive" usage. Small writes will bring this drive to its knees.
this sig was brought to you by the letter
The high end ones have scored metal cases too to produce handgrenade style shrapnel.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
Turned out it didn't fully support DMA...??? Like they didn't complete all the traces properly...
This problem is rampant in many flash card models and brands - even ones that claim to support DMA or UDMA. Search around on the interweb using your Napster machine and you'll see many others with the same issues.
:)
After trying a Transcend 4GB 133x that would only work in PIO mode, I got my hands on a Ridata 4GB 266x that *does* work in DMA. So if anyone is considering that card, maybe that's a good sign.
Mechanical challenges turned out to be not the only ones waiting for me when I worked on connecting the CF cards to the camera. These cards were hanging when the CPU tried to read them using DMA mode (and the card identified itself as supporting DMA mode). I tried to find the problem, and used all the tools I had. I added a bunch of printk's to the driver source, tried different speed settings for the DMA, and finally used an oscilloscope to spy on the signals between the CF card and the CPU. What I found was that the card did actually send the data using DMA mode, but always only for two "sectors" (1024 bytes total), regardless of the number of blocks to transfer written to the corresponding register. Then it silently hung, without activating an IRQ line, even if it was asked to transfer just a single block. And the CPU was relying on that interrupt to continue with the processing of the data read from the CF card. Careful examination of the data on the IDE bus did not reveal any problems (I was expecting something specific to the ETRAX). The same CF card with the DMA mode disabled in the driver worked fine (but slower, of course), as did the IDE hard drive (or SATA through the bridge) with DMA enabled. Googling the issue showed that I'm not the first to have problems with CF cards and DMA. The driver itself had a blacklist for some of the devices that caused problems. -- http://linuxdevices.com/articles/AT5102023409.html
Fact: Everything I say is fiction.
I hope it's not something important in that outlook PST. Because PST files are a really ugly data format, that are horrifically prone to corruption and just generally 'not working'. If it's important to have archives, the tool for the job is archiving it. Not keeping it in massive piles of 'maybe I will need it' junk on your HDD.