Intel's Braidwood Could Crush SSD Market 271
Lucas123 writes "Intel is planning to launch its native flash memory module, code named Braidwood, in the first or second quarter of 2010. The inexpensive NAND flash will reside directly on a computer's motherboard as cache for all I/O and it will offer performance increases and other benefits similar to that of adding a solid-state disk drive to the system. A new report states that by achieving SSD performance without the high cost, Braidwood will essentially erode the SSD market, which, ironically, includes Intel's two popular SSD models. 'Intel has got a very good [SSD] product. But, they view additional layers of NAND technology in PCs as inevitable. They don't think SSDs are likely to take over 100% of the PC market, but they do think Braidwood could find itself in 100% of PCs,' the report's author said."
Comment removed (Score:5, Insightful)
Comment removed (Score:5, Insightful)
How about the reliability ? (Score:3, Insightful)
Re:The writing's on the wall. (Score:5, Insightful)
Just goes to show how warped a professional's perspective really is. Standard consumer with 4TB of data? Really?
Re:HW buffer for drives (Score:4, Insightful)
I agree, but why would Intel want to use flash memory for this? RAM is faster, has the capability of a LOT more read/write cycles, and could be backed up by a small battery in the case of short power outages (or maybe a battery big enough to run the hard drive long enough to flush the write buffer, as others have said).
This is essentially a cache, which means it's going to get a lot of reads and writes. Under those circumstances, the flash memory's going to wear out relatively quickly and unless it's easily replaceable it means everyone's going to need to buy new motherboards every year. How could forcing people to replace motherboards annually possibly benefit Intel? Oh, wait...
Re:why flash? (Score:2, Insightful)
Your OS doesn't always have time to shut down properly. Don't think anyone's fond of the idea of having their last couple of saves go poof because Windows crashed.
Intel's SSD drives already have 32MB of DRAM. But it's not used to buffer data because of reliability issues.
Re:Not so sure (Score:5, Insightful)
I can't take the flash to the next PC as i can do with the SSD.
Not really a big deal; if it becomes commonplace, most PCs will eventually have it (or something like it) as standard anyway and you won't be bothered about it.
Re:The writing's on the wall. (Score:3, Insightful)
The RIAA and MPAA would have you believe that each man, woman, and child has downloaded at least that much illegal movies and music.
Re:Bullshit (Score:3, Insightful)
Random I/O is essentially uncacheable.
I'm sure that would come as a great surprise to anyone who ever implemented a virtual memory system.
His flaw lies in assuming- or implying- that most I/O *is* random.
Re:The writing's on the wall. (Score:3, Insightful)
Re:Not so sure (Score:5, Insightful)
Whoever defined parent as troll must be weird.
That said - I'm more worrying about the consideration about exhausted flash on the motherboard. Have all avenues actually been considered here, or is that a built-in best before date that new motherboards will have?
Re:why flash? (Score:3, Insightful)
Re:Bullshit (Score:5, Insightful)
Random I/O is essentially uncacheable.
I'm sure that would come as a great surprise to anyone who ever implemented a virtual memory system.
-jcr
You're both right.
The problem here is that "random I/O" can have at least two subtly different meanings. In the very old days they talked about random I/O as opposed to sequential (ie, tape) I/O. In that sense, yes, random I/O is often extremely cacheable, as you say. That's why virtual memory works, as system files, drivers, commonly-used applications, and so forth are accessed much more often than other daa.
"Random I/O" can also refer to I/O that does not follow any real pattern - ie, a 50GB database in which all records are accessed about equally as often. This kind of I/O is not really cacheable, practically speaking. Unless you can cache the entire thing.
What's the correct terminology for the second kind of random I/O? Random I/O with very low locality?
Re:The writing's on the wall. (Score:5, Insightful)
Re:HW buffer for drives (Score:2, Insightful)
It's called planed obsolescence. Due to the amount of read/write cycles on the i/o and the fact all flash memory is limited to a certain number. If they integrate this into the motherboard it means that the motherboard has a expiration date they can predict and design around. In such a situation the flash will mostly last about a year or 2.
Speed has nothing to do with it because your /still/ bound to the data flush to the disk drive which will be much slower. data security between crashes seems to only be a side benefit.
Re:Bullshit (Score:3, Insightful)
1. SSDs handle random I/O extremely well compared to traditional harddisks.
2. Braidwood is essentially a small, cheap, 8-16GB flash based cache.
3. If Braidwood is transparent to the OS, it will have a hard time guessing what to put in the cache, because a lot of the I/O on a desktop/laptop is random, but the issue with caching the non-random part is that most OSs do caching themselves for frequently accessed parts of the disk. This means that for a transparent caching solution like that it is very hard to tell the difference between a frequently accessed piece of executable data and random I/O, since in both cases, it only gets accessed once per startup/shutdown cycle, for frequently accessed stuff it is already cached in memory, for random I/O, it is simply never requested again for a long time. So to make this caching work the flash thing either needs OS level support or very sophisticated statistics collection specifically tuned for keeping track of patterns across reboots and providing a caching solution for startup basically.
Comment removed (Score:4, Insightful)
Re:fsync(fileno(fp)); (Score:3, Insightful)
I'd answered yes, but one doesn't control the fsync behavior of every application running on his/her system and the OS/file system can take a lot of time (even tens of seconds or more) before deciding to commit changes to the hard disk. Furthermore, a fsync may take seconds to complete and disaster can strike at any time.
There was quite a commotion about those matters when somebody filed a data loss bug [launchpad.net] against the new Linux ext4 file system in January 2009. It turned out that ext3 commits changes at least every 5 seconds and ext4 does it less often. Some applications that got lucky with Linux crashes on ext3 exposed their poor design when running on ext4. Comments #45 and #54 in the linked page are quite explanatory.
By the way that was a sloppy application coding problem (if you want your data safe on HD you fsync and wait as long as it takes to write them down) but they eventually issued some patches to the file system code to mitigate it.
Re:Not so sure (Score:3, Insightful)
TFA says it'll be used for an I/O cache, so I supsect it'll get hit slightly more often than that.
Re:why flash? (Score:3, Insightful)
Re:Not so sure (Score:5, Insightful)
Re:Not so sure (Score:3, Insightful)
Actually if it's a cache the size could just reduce as the flash wears out.
What nonsense (Score:5, Insightful)
Is this the latest FUD? That if a company brings out a successful product that's priced cheaply it'll "erode the market"?
How did the :"market" become so sacred that it must be preserved at all costs by keeping prices high? It's really funny the crap that'll come out of an MBA's mouth. He'll be all for "free markets" until someone comes along with a better product and then he'll start to squeal that the "market" is under siege.
Good for Intel.
Re:Not so sure (Score:3, Insightful)
With intelligent cache techniques you should be able to get the erase-cycle count for each block very low.
Re:Not so sure (Score:3, Insightful)
I would expect they'd be using some sort of slot, something like this [scan.co.uk]. Motherboard manufacturers aren't exactly going to be thrilled at the idea of putting some yet more expensive components on there, but they might be happy to hook up a small ZIF socket thing like some of them do with CF.
Intel actually had some weird ZIF connected SSD's on there a while ago on preorder, but they appear to have disappeared.
Either way, it's nice to see some hybrid storage stuff which isn't ZFS L2ARC (zpool add tank cache /dev/my_ssd -> tank now has an 80GB SSD for fs cache). Kind of surprised it hasn't been done in software elsewhere really; you'd think there would be some Linux developer who found the idea compelling, or even Microsoft wanting to extend ReadyBoost to its logical conclusion.
Re:Not so sure (Score:3, Insightful)
64bit OS + FS buffer cache (Score:3, Insightful)
Just add the extra 32GB of RAM to the OS, and let it more intelligently manage the data.
Re:why flash? (Score:3, Insightful)
It's that time of year. The one time every annum when I respond graciously to a request without becoming belligerent. So there you go.