Slashdot Mirror
Intel's Braidwood Could Crush SSD Market
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."
When given similar performance but a slightly higher price, i would prefer the SSD. I can't take the flash to the next PC as i can do with the SSD. Hard disks have a highe life expectancy than mainboards (i usually find some good use for old HDs, i never did for old mainboards). Unless the SSD will cost 2-3 times as much as the flash on the mainboard, i believe SSDs will still be used. But maybe this will lead to lower SSD prices.
I mean, why not put cheaper DDR RAM on the motherboard, with a big capacitor or battery to allow it to flush all writes out to disc when the power stops?
In fact, why bother putting ram as an IO cache when you could add the RAM to the motherboard anyway and allow the OS to cache writes. Intel - stop thinking like this, and just hand out free 1GB DRAM sticks with every motherboard, job solved.
Sooner or later, no moving parts beats moving parts. The magnetic disk makers have done an amazing job so far, but eventually they're going to lose out to solid-state.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
Now only if they could start following the server side folks and place an internal USB connector inside and then MS and others could give us the OS on its own usb drive (read only) and we could use the hard drive for updates and programs we could enhance the security as well...
Life is but a Beta test...
What does it do, scream "Nooooooooo!" and throw itself underneath the hard drive in slow motion?
If you were blocking sigs, you wouldn't have to read this.
I really don't want to contemplate having my boot volume on a USB device.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
Sounds like a good plan. Throw cheap battery backed memory, 4-16Gb onboard to act as a transparent buffer between harddrive(s) and system.
Fast IO is ensured as most operations happen in memory, and dataloss isn't an issue as the memory is battery backed.
RAID cards have done this for ages, but it's becoming real option for desktops as memory price keeps declining.
16Gb might be overkill for most purposes, you could get away with 2 if the system is used only for low-power tasks like surfing and email.
There are no atheists when recovering from tape backup.
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
The only title of honor that a tyrant can grant is "Enemy of the State."
There have also been rumors, however, that Braidwood has been canceled, at least in the near term:
http://www.dvhardware.net/article37368.html
If the onboard flash is a cache, that means it will be used frequently do it will wear faster. Won't that mean you're more likely to corrupt your data, even if your HD is still good ?
Not really. I don't doubt that Braidwood would increase performance since I/O be it memory or disk is not entirely random - there are parts of the memory and disk more frequently accessed therefor cacheable. Oh btw, by cacheable I mean "non-marginal" performance benefit for using the cache. Even with random I/O, having a cache can increase performance a bit, but only very slightly.
Memory is usually cacheable a lot better than information on the disk however. Caching the operating system related files and executables on something like Braidwood would speed up things a lot, but it would be useless for any other area where high performance is needed, like gaming or working with larger files in general.
It takes a man to suffer ignorance and smile
Be yourself no matter what they say
If intel has made an SSD that dont wear out ffs sell them to me now. If not, then stuff that cache somewhere the sun dont shine and come up with a better solution.
HTTP/1.1 400
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.
You should assume the word "Random" is in bold-type, then the claim makes more sense.
Virtual memory systems only work effectively to the extent that data access has 'locality of reference' - which is often, but not always, found in practice.
To my mind, the real promise of solid-state is the random access. Since the earliest DP, software has had to take into account the sequential nature of access to durable storage - disk based storage never did have a uniform access time for blocks - and this has influenced everything from file-system design to memory architectures. In an SSD environment, it becomes possible to accurately model performance at higher levels of logical abstraction - and, in my view, better systems should emerge as a consequence... assuming, of course, the world at large doesn't do something crazy - such as always access flash through a FAT file-system... LOL!
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.
"Slashdot - News and Chat Sites Deviant". (Click "homepage" link above for details).
Funny - this very thing was being discussed around 1985 (I think), but using battery-backed RAM as a way to reduce boot time. The thinking was people wouldn't put up with a computer that took 30 seconds to start, and if we didn't have a 2-5 second boot time (equal to a TV), the personal computer would never fly. But since it took from 1985 (80386 chip) to 1995 (Windows 95) for a 32-bit OS to become popular, maybe 25 years is reasonable.
Or not. Man, this industry moves at a snails pace in a lot of areas. Why do we still live with the x86 instruction set. Is "the year of UNIX" here yet?
Anyway, three competitors will emerge:
- Someone will put NAND directly on the drive, and get an instant speed improvement. All the tech sites will rave about it and it will be an instant must-have item.
- Their competitor will figure out a way to put the OS files in NAND, for fast booting, via a utility or firmware. The marketing war begins.
- The third competitor will work with Microsoft or Apple to get OS support for fast boot. Apple will get there first and you'll see a commercial on TV with the Mac guy wondering why the PC guy takes the entire commercial to wake up.
In a single drive system, the cost will be about the same. Doing it on the drive will create an instant performance boost on any machine, and well worth the estimated $10 added cost.
Place nail here >+
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?
OtakuBooty.com: Smart, funny, sexy nerds.
It's more the case of hedging characteristics against each other.
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.
It takes a man to suffer ignorance and smile
Be yourself no matter what they say
Random I/O. The first is called non-sequential I/O.
It takes a man to suffer ignorance and smile
Be yourself no matter what they say
there is a finite time before changed data are permanently stored even on this new SSD menory. Furthermore that time can be quite large depending on the OS and file system design.
If you flush and sync the file in the thread that writes the file, you can be sure that "[t]he fsync() function does not return until the system has completed [writing data] or until an error is detected." By "that time", do you refer to the time that the program blocks on fsync()?
Why a USB connector ? That causes the same problem as making SSD cards use the SATA interface - the serial interface becomes slower than the things it is connected to.
What I would like to see is a set of sockets on the motherboard, mapped into the main memory address space (not PCI), a physical switch on the board to make them read only and software in the BIOS to make them look like a bootable disk.
Four sockets with 16 or 32G in each would give you enough space to store the entire OS. I don't know how Windows would handle it, but in a Unix or Linux based system it would be fairly easy to mount the devices as read only partitions and map them into the filesystem. This would be ideal for a server system, mapping the entire OS into the main memory address space and making it read only.
In fact all the BIOS would need to do is make the first 100M visible as a boot partition, and leave the OS to handle the rest.
From TFA: "Braidwood, which is expected to offer anywhere from 4GB to 16GB capacity, ..." - In what way would it even compete with the SSD market? I'll stick to my separate 250 gig SSD drives for a while longer methinks.
I RTFA and still fail to see how this will "erode the SSD market". For example, I have a drive with 100+ GB of data on it (music, photos, documents, source code, backups)... my interactions with that drive are completely random and unpredictable. Yes, you COULD cache the entire source code folder when I start up my IDE, but what if I want to listen to some music on shuffle while I'm doing that, or add an image file from the photo directory to the source code... there goes the caching strategy.
When comparing that cost increase with the overall cost of a brand new PC it doesn't raise any red flag. Nonetheless, what it must be said is that, as this brainwood technology "resides directly on the motherboard" (i.e., it's yet another component embedded in a motherboard) , this technology will increase all motheboard cost by $10 to $20. That means that this brainwood technology is an excuse to ramp up current motherboard prices from around 20%.
Call me old fashioned but I prefer my hardware cheap without any unnecessary bells ans whistles. In fact, is this technology even capable of doing what the marketing blurb states it does? Nowadays it's hard to purchase a HD with capacity less than 200GB. Is a 4GB buffer really capable of successfully buffering all that data?
Slashdot, fix your code or at least hire someone who is competent at it to do it for you.
Brownian noise vs. white noise?
This used to be a huge PITA before GRUB supported UUIDs as groot values. It was an even bigger one before Linux would do it. On Windows you need special tricks, because Windows doesn't like to be installed there; it works on some netbooks with "special" BIOS. I think the specialness is at least partly from their EFIness but I'm just kind of firing in the dark here. I have a 4G Surf and an Aspire One, both will allegedly play this trick. Actually, I have a DT Research DT366 which seems to have some sort of USB disk emulation mode also.
I have used a SDHC in SD adapter (16GB Sandisk) as root for Linux on both the above systems and aside from some slowness (~5 MB/sec, but the 5200rpm disk in these systems is pretty damned slow anyway) it works great. I used XFS as the root, it plays well with such devices as far as journaling filesystems go. So this is actually a flash card in a multi adapter on the USB bus in both cases, and worked great. I have also installed a 4GB Sandisk flash into the internal USB port on an add-in card in my desktop system and used it for ReadyBoost, but that system now runs Jaunty. Having more bootable devices increases boot time, so I just boot from the disk. It would be easy to mirror /boot to flash but there's little to be gained speedwise by doing so little. If you union mounted a flash volume with files needed at boot over the actual boot volume... eh, now I'm just being silly.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Random I/O is essentially uncacheable.
I think you mean "unpredictable" here, not "random".
Random I/O is hard to read cache it is very write cache friendly. Modern systems already have huge a huge read cache called all unused memory. A huge nonvolatile write cache can do wonders for random write I/O. Databases and the like can often write the same block multiple times in succession over a long period only the most recent needs to be written to disk. I/O can be reordered to be more sequential helping seek times (yes drives already do this but with 32 megs vs gigs of flash), take this further and the flash could literally write all pending changes from the beginning to the end of the drive and then start again making all drive write IO sequential (Baring internal drive sector remapping, of a need to read uncached data).
No sir I dont like it.
The buffer should obviously be on the hard disk. That way the data on the disk will always be in sync, even if there are writes buffered in the flash cache when the computer loses power. I can't see a good reason to put it on the motherboard instead. Especially as most consumer systems have exactly one HDD.
The article says that the flash buffer could work for "all system io". I can only think of optical disks and flash drives possibilities other than hard disks. But optical disks are interchangeable, so they have to be reread on each use anyway, and could just as well be cached in RAM. And it makes no sense to cache flash drives in flash cache...
On Windows you need special tricks, because Windows doesn't like to be installed there; it works on some netbooks with "special" BIOS. I think the specialness is at least partly from their EFIness but I'm just kind of firing in the dark here. I have a 4G Surf and an Aspire One, both will allegedly play this trick. Actually, I have a DT Research DT366 which seems to have some sort of USB disk emulation mode also.
Basically, it just needs to appear to the OS as a "fixed disk" rather than a "removable disk".
Why would you need 4x16G for the OS - Vista doesn't even take up that much...I was thinking of starting with around 8G for Windows and uses a union FS to map Windows updates over the original files.
No user programs here - interface-wise I wouldn't care that much - USB is everywhere and slow, but drop in SD or compactflash and I'm ok. More of purchase an OS on flash drop it in and nothing can touch it - if I need to wipe no big deal just rebuild the config files and clean out user data, and no more friggin programs writing files into c:\windows...
Life is but a Beta test...
I'm not married to USB CF or SD would work - something semi-portable would be for the best - as I would like to see the OS and OS only on the flash memory - maybe a couple gigs of that space wwould be writable for config files...
Think boot/OS disk...I'm all for speed, its just that USB is everywhere.
Life is but a Beta test...
What I would like to see is a set of sockets on the motherboard, mapped into the main memory address space (not PCI), a physical switch on the board to make them read only and software in the BIOS to make them look like a bootable disk.
The one issue, here, is one of address space. Unless people do a wholesale migration to 64-bit, it won't be possible to simply map the address space of such a device into memory.
Databases and the like can often write the same block multiple times in succession over a long period only the most recent needs to be written to disk.
But each write still needs to be written to a non-volatile journal; otherwise, the database is not durable.
one doesn't control the fsync behavior of every application running on his/her system
Users can choose applications that properly sync, or in the case of free software, they can put fflush(fp); fsync(fileno(fp)); in strategic places and recompile. Braidwood, which appears to implement a nonvolatile ring buffer for writes, should make it less painful for application developers to sync when appropriate.
By the way that was a sloppy application coding problem
That, and the fact that fsync() doesn't provide any sort of reasonable performance guarantees. Some of the slowdowns of Firefox 3.x on netbooks are due to an SQLite COMMIT (which calls fsync()) taking several seconds to flush writes to a cheap HDD or cheap SSD. That's one thing this Braidwood chip is intended to correct.
No, it's called direct access (the DA in DASD, and also the reason for the FreeBSD device name for SCSI hard disks). If you're talking about RAM, though, it's acceptable to call it random access.
Hybrid drives are a few years old, but apparently not very popular.
Samsung makes some with 256 MB of on drive NAND flash.
I do have to question the effectiveness in multiple drive scenarios. And they talk about 4 GB of space - how do you avoid getting your page file stored on it? And how quickly will the 4 GB be worn out and read only? From the latest AnandTech article on SSDs:
7 GB of data, 4 GB of space to store it. And since it's only going to be used as a sort of intelligent cache, you'll have a lot of erasures, as you'll be moving data off of the cache onto the harddrive to make room for new stuff, and back onto the cache again.
They say they'll use SLC, but how quickly will the OEMs demand MLC for lower end models and thus cut the number of write cycles by 10?
And at what point can you be certain that the document you've been working on for several hours a day for the two weeks is stored on the laptop's harddrive and not on the cache? It's bad enough when your laptop dies on you and you have to send it in for repairs, but if you cannot be certain that your data is safely tucked away on your removable harddrive ... especially if it's the motherboard that developed a failure.
It's a nifty idea, but for stuff like this I'd be worried about data safety more than performance gains. I can get performance gains by putting an SSD into my laptop right now and I know that I can remove the SSD again if the computer needs repairs.
Why do we still live with the x86 instruction set.
Three reasons:
This is why I keep hoping someone will produce a complete computer architecture designed to be virtualized, so that I can genuinely run Windows and Linux (for example) and have both have access to the hardware. I'm tired of deciding who can access the video card. On a system with unified memory it seems especially silly that I can't do this gracefully.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
If the onboard flash is a cache, that means it will be used frequently do it will wear faster. Won't that mean you're more likely to corrupt your data, even if your HD is still good ?
NAND flash chips are generally guaranteed for at least 100,000 erases per block. As I understand this Braidwood chip, it's a non-volatile ring buffer for data writes. Ring buffers are the easiest thing to wear-level, meaning you can just multiply the cache capacity devoted to writes (let's say 2 GB) by the longevity guarantee to get 200 TB of buffered writes before any failure occurs. And not all blocks on a flash chip fail after the same number of writes; you'll just start to lose ring buffer capacity over time.
If you're going to flush/sync after every write, you might as well not have a write cache at all.
And if you're not going to flush/sync after every write, relying instead on a volatile write cache that may or may not get committed before power loss, you might as well not have files at all. But with a nonvolatile write cache like Braidwood, on the other hand, half of a sync can happen before power loss and half after. Writes doesn't have to wait for the hard disk to spin up; instead, they can proceed, and the OS will spin up the hard disk when it's ready to commit.
I have an SSD for increased reliability, heat ans shock resistance on some of mu data. This mainboard-contraption does nothing in that direction.
Also, depending on usage patterns, it should be far, far inferiour to memory buffer-cache. I think this is a publicity stunt.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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.
You are welcome on my lawn.
Unless you are making some extremely teoretical scenario, in which case the I/O is not really random anymore, you will still statistically hit some data in cache and you will hit more the more cache you have vs. data. For instance, if your cache i larger than the data, then random I/O will be 100% cacheable... Also, while the read might have low cache hit rates (which is more correct than saying it is not cachable), a NVram cache can still give you great benefits on writes as it might open for better write scheduling. That is, you can delay the flush to disk and coordinate that better with head movements which can significantly speed up things.
long enough to exceed the lifetime expectancy of the flash?
* Winners compare their achievements to their goals, losers compare theirs to that of others.
He has a point, though. If you're trying to cache a 2TB drive with a 4GB cache, there's only so much you can do.
Besides, I've got 12GB of RAM in my system, and most of that gets used as a disk cache. The performance still saw an enormous boost when I moved to SSD. What can on-mobo flash-cache do that a similar amount of RAM cache couldn't? Colour me skeptical.
I would want any on-mobo items to outlast the computer, or at least degrade gracefully.
In certain environments, pinning should help with wear-level. For example, in servers, pinning files that load at boot or pre-loading files likely to be needed at boot during a non-reboot shutdown will speed up boot-time, and on any system good cache management systems that are aware of what causes human-perceptible delays and what doesn't will help as well.
In a human-in-the-loop environment to help guide decision-making, multi-boot environments can pin boot-time files for multiple OSes in the cache, making it faster to swap between OSes.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Most motherboards already have internal USB headers.
I suffer from attention surplus disorder.
Just add the extra 32GB of RAM to the OS, and let it more intelligently manage the data.
I want to delete my account but Slashdot doesn't allow it.
okay so "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" to me means that they're adding a big 1GB, high speed flash cache chip to the motherboard. Like you're writing a file to the hard drive and it goes straight to cache and says "okay, finished" then slowly sends it to the hard drive. That would simulate SSD write speed but only on the surface.
Okay, so who wants a 30 second delay between when the file says it's done trasnfering/copying/saving and when it's actually on the hard drive? Write caching is a horrible idea that corrupts hard drives and loses files if you power off at the wrong time. Get one of those on your motherboard and you're basically guaranteed to never, ever be able to force shutdown or restart it with the instant restart button on the front of your case. Technically any data still on the flash chip would be saved and could resume transferring to the hard drive when you power back on but the file it was currently working on just got split in half on the hard drive!
Google's Super Secret Search Algorithm: SELECT @search_results FROM internet WHERE @search_results = 'good'
You wrote "Or not. Man, this industry moves at a snails pace in a lot of areas. Why do we still live with the x86 instruction set. Is "the year of UNIX" here yet?"
Actually, when you are in 64-bit mode, you are most certainly not using anything like the classic x86 instruction set. There are many more registers, and the limitations on specific register uses are mostly gone. x86-64 very much changed things for the better.
I STILL don't find anything to rant and rave about when people start talking about SSDs....having worked for a fair while as IT technician I've seen some Netbooks come in with major hardware failures and when they're in guarantee we have to send them off to Acer elsewhere in the coutry, and they have a "I don't give a crap about your documents" policy that means that they format your C:/ Drive also meaning if the customer has documents that need saving we (currently anyway) don't have any way of recovering those documents from a SSD. ...just thought you'd like to know if your computer habits usually end in visits to IT Assistance...
this is a virtual insanity that always seems to be governed by our love for this useless twisting of our new technology.
Would you have to open the computer case every time you installed an OS patch? If so, would that make your system more or less secure?
Expected time to finish is 1 hour and 60 minutes.
This will have minimal impact on the adoption of SSDs ( well for smart consumers ). What it might do, is reduce the amount of RAM
that gets installed by default. 4-16 GB is ridiculously small as a substitute for mass storage but right up there with volatile RAM.
Also, the best way to speed up a system is to increase the performance of the slowest subsystems ( especially if they're heavily used).
Right now, that would be magnetic, rotating hard disks. And, Intel is not so stupid as to undercut one of their own products that's
clearly better than any competing product at the moment.
Pain is merely failure leaving the body
in a Unix or Linux based system it would be fairly easy to mount the devices as read only partitions and map them into the filesystem
That sounds just like Asus's Expressgate: a Linux OS on the motherboard independant from the main OS
I run Ubuntu server as a NAS, booting from an 8GB Patriot XPorter. Not fast, but easily fast enough for what it's doing, and one less noisy hdd giving off heat. I can't say I would hope to do that for desktop use though.
I am literally 3000 tokens away from the chaotic crossbow --Stephen
What's new about this exactly? I have I2O controllers with on-board cache from ten years ago, and we had RAM-based PCI cards for caching back in the nineties on some servers I administered.
So now Intel's just integrating a cheaper I/O cache into the backplane ... flash instead of RAM ... big deal, and hardly innovative. Its also not going to help streaming data speeds at all, which will always rely on spindle speed, nor random access of changing data for that matter, only data that can be cached -- which is why we've been doing RAM caching for all these years.
- Michael T. Babcock (Yes, I blog)
What's the correct terminology for the second kind of random I/O? Random I/O with very low locality?
Dunno, but the correct terminology for the first is "Random Access" or "Random Access IO" -- not "Random IO".
I'd have thought that without OS support whatever things braidwood magically decided to cache would also be cached by the OS. Looking at my desktop here it has almost a gig of memory used a cache. If I had a 2 gig Braidwood then half of it would presumably be wasted if it wasn't intentionally caching things the OS wasn't. I suppose you might get a one off improvement on boot but then again the boot process is probably going to hit a lot of files that aren't used thereafter and so won't be in the cache any more.
Boffoonery - downloadable Comedy Benefit for Bletchley Park
This is something that I've been wishing we had some solutions for -- some multi-level cache whether it's like traditional hierarchical storage or not...
/var/lib/pgsql/data/pg_xlog on different spindles, and Linux will make use of excess RAM as cache, we don't really have the ability to make use of 80GB of SSD as just a straight cache for a 1TB drive.
While we do have some ability to do things like put the journal or
This is something I've been wanting to write, but just haven't found enough
roundtuits... I figure it could be implemented as a dm module in Linux
sitting in front of the back-end block device, with fancy data-structures
for handling infomration about what blocks to cache.
ZFS has recently added some ability to have the journal *AND* a cache device externally, but in my testing of it the performance really didn't improve.
I've also been thinking about the next generation of RAID cards... I can imagine them having some ability to augment their RAM-based cache with a much larger SSD. Volume X is just to be used as a cache for volume Y. Then you put 4 2TB spinning discs in as RAID-5, say, and 4 80GB SSD drives in as RAID-0 cache (if it's a read cache then all the data is redundant from the spinning discs anyway) or RAID-whatever if you are storing write cache information on it...
So who is going to get to market first? Intel with it's motherboards, or the RAID vendors? Adaptec already has a card with 4GB of flash on it, that it seems to just use as permanent storage for the RAM -- powered by a supercapacitor to give it the time required to write the DRAM to flash. They are pushing this as "A BBU that you never have to maintain". But I could easily see the fluash expanding to be much larger and being used to cache more.
Sean
"And it doesn't involve the Flash being placed in the drive."
What I mean by that is, that this discussion is about something fundamentally different from what the original poster described. Go back way up in the chain, someone was talking about some sort of SSD built-in to the HDD. But such a device cannot know about what files are in what directory, and cache them accordingly. It only sees sectors. Like for example, it could not know that files in the "temporary internet folders" directory doenot need to go to the permanent storage.
So my statement was to clarify that an on-disk SSD could not do what you have done.
Your comments are prime examples of one of the reasons why I hate USB:
iNTEL sells it as a cure-all.
There is absolutely no reason at all to put that many hardware and software layers between the CPU and flash you're mounting (or socketing) on the motherboard. Built-in floppies, well, yeah, sort of. Maybe. (But I'd still rather the defacto standard for slow/small mass storage/IO devices to have been not so, well, braindead.)
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
Let us all praise intel for getting yet another thinly veiled attention grab on slashdot!
(As noted already above.)
Or is it for putting their own product markets at risk to grow another product market? No, these are not competitive products, except in one particular application (boot media), as also noted above. (Not that you necessarily would have seen the comments above. I didn't check the posting times.)
Sure does seem to be a lot of misunderstanding about the purpose of this product. Not that I appreciate it that intel is building the chipsets for both the mobo and for the on-board bulk flash, without, apparently, publicly referenced standards (Or did I miss something?), but the basic idea is one whose time has come.
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
The fan?
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
The one idea I've not seen talked about that seems like it'd help magnetic disks is to just store the first megabyte or so in cache, so that the disk can seek to the next part of a file and read at whatever expected transfer speed. In other words, cache away the seek time and live with the transfer. It seems like a nice match for an SSD cache if the goal is to pretend you have a huge SSD storage but can't afford it. It'd stretch the cache across a whole lot more files, so that almost all files could appear to live in cache. Well, if the number turned out to be as high as 1 MB than I guess 16000 files could live in it, not accounting for smaller libraries that could fully fit within it.
pimtamf