Thought experiment: HDD with flash read-cache?

So, lately i've been skimming through a few old articles and papers on HDD/RAM and newer Flash/RAM hybrid drives. After looking at the specs and contemplating architecture a bit, i was left with a question:
Why hasn't any HDD maker yet added a flash read-cache?

By adding a single 4-8GB MLC NAND chip, costing roughly $2-3/GB = $8-24 added cost, and using it for read-caching hot-files, you can get around 4-5000 4KB random read IOPS = 16-20MB/s (@QD 1) and roughly 40-60MB/s sequential read for the cached data. And since it's a read-cache, write speeds and write cycles will be largely irrelevant.

Tracking hot-files should be easy to implement simply by logging read-access to LBAs, and with a slight bit more effort, filtering LBAs being read in a small block random pattern. Possibly also caching file-table and folder/file structure and metadata, as well as the data typically read the first seconds after power-up or spin-up. This could allow low-power "green" drives to not spin up everytime you access it if you don't need un-cached data, and could also allow the drive to spin at a lower speed while delivering adequite performance. Lower rotational speed could also allow higher storage density.

Using this type of caching would have a noticable effect on typical usage patterns, and especially multi-tasking, but would likely not make an impact on benchmarking since it would take some time for new data to reach cache.

Larger hot-files could benefit from the cache as they could be read from both flash and disk at the same time with the speed of both combined (80-140 + 40-60).

With a custom driver (or a mini-USB port?) you could also have a tool-box to allow advanced users to manipulate the cache. Filtering by filetype, file size, heat (frequency of access, both short-term and long-term), location, etc.

The failure of a cache of this kind is not (or does not have to be) fatal for stored data or even function of the HDD.


Any thoughts people?
Does this sound doable, and if so, to what extent?
What kind of drives would benefit the most and be acceptable with a bit higher price and performance?
Would HDD makers consider this or do this if it was doable and there was a market?
(I think it's doable at least with simple LBA access frequency logging, and there being a market in almost all segments, however niche in some)

becuase they want you to buy ssd drives for rediculos ammounts of money instead>? becuase people dont want in between speeeds they either want normal/bleeding edge of technology?

As an interim measure this would be a good viable option. Mixing technologies as you propose should be able to give SSD performance, larger capacities and cheaper prices, however as SSD’s become more mainstream and prices drop to HDD levels and capacities increase the value proposition would quickly disappear. I guess the question is how long would it be a viable option and how much would it cost to develop?

You would have thought that Western Digital would have considered this, but then again it’s amazing how big companies are disjointed when it comes to combining technologies. (Raid trim support and Intel come to mind quite quickly).

@NKrader: That makes sense for two harddrive makers; Samsung and Western Digital.
None of the other HDD markers have SSD for the consumer market.

My point is it would be a great value-add that would own competing HDDs, and would allow "green" drives consuming even less power while at the same time boosting performance for general usage.

If the implementation is made in the easiest way i've mentioned above, it won't take much R&D either, and since using this kind of cache is (or can be made) none-fatal to the drive if it fails, there is very little risk of angry customers.

Samsung had a go at it a few years ago :)
The Samsung Hybrid drive, Link to extremetech, Link to PCWorld

I see i partially answered you there audienceofone whitout seing your post :P
What Intel did to it's G1 customers can be simplified as burning them, you don't get away with that many times before people start to boycott you...


Regarding the timescope in wich this type of cache/hybrid sollution (not really a hybrid though with a single chip, a hybrid would be more like 4 chips with NCQ for 20K IOPS read and 160-240MB/s seq read), it will depend on what segment it's done in.
It can have a 5 year lifetime in "green" drives as a power-saving meassure while at the same time increasing average random IOPS. (3-5 generations/versions of drives)
For "black" drives it will likely have a 2-3 year lifespan for higher capacity drives as a IOPS boost for capacities that are too expencive as pure SSDs. (2-3 generations/versions)
Used as a f.ex. a more real SSD-HDD hybrid with 4 NAND chips in parallell with NCQ it could have a lifetime of 2-3 years as well. (2-3 generations/versions) Such a device could also do random write caching, and/or burst write boosting, as well as seq read boosting of large hot files.


EDIT: @anvil, if i remember correctly, it used only a small amount of flash, and required OS support, wich was not ready for it. What i'm talking about here are "true" cache/hybrid drives that are "plug n play" under any OS.

They had plans but I don't think it worked out the way they thought.

"Andy Higginbotham, director of sales and marketing for Samsung's Hard Disk Drive Group, notes that NAND flash's cost per gigabyte is expected to decrease by about 50 percent per year. Considering that timeline, Higginbotham says, we can expect to see hybrid hard drives incorporate 512MB of flash in 2008, 1GB of flash in 2009, and 2GB in 2010--all for the same cost as integrating 256MB today."

It might still happen but I have doubts.
I'd say, HDD's for storage and SSD's for speed :), there may be a market in between.

It's a great idea though, this way notebooks/small laptops and low-mid end computers could have the "best of both worlds".

I remember reading on storagesearch.com a couple of years ago that that samsung HDD-flash hybrid drive depended on Vista for usage of the flash component, and that it was poorly implemented. The tiny size of 256MB wouldn't do much good used in the way those reviews you linked seem to indicate.

A 4-8GB flash cache on the other hand is enough to cache all files on a W7 installation below 1MB, in addition to some hot files.

If i were to set the caching parameters by the simplest form of LBA read-access tracking filtering wich can be done entirely onboard the disk, i would set it to cache anything read at 4-16KB chunks in a random (or single sequential) access pattern, and then go on to caching the hottest LBA blocks in the 32-128KB range. And after that, cache anything read within 10-20 seconds of every (or most) power-on that would still fit in the rest of the cache.

EDIT: the added ca $20 for 8GB MLC flash would easily be justified by the added performance in 1-2TB 3,5" HDDs and 500GB+ 2,5" HDDs used for OS, programs, and games.

Have you come across this before? http://www.dataslide.com/technology.html

I don’t know much about it but the concept seemed quite cool. Performance is not so bad either. :cool:

Hard Rectangular Drive
160,000 IOPS & 500MB/sec and low power <4 Watts for a magnetic storage device:
1. A piezoelectric actuator keeps the rectangular media in precise motion
2. A diamond solid lubricant coating protects the surfaces for years of worry free service
3. A massively parallel 2D array of magnetic heads reads from or writes to up to 64 embedded
heads at a time

I've seen it before. It would be cool if it worked, but if it worked, there would likely be more fuzz about it and prototypes demonstrated.
160.000 IOPS, it does not say random or sequential, or at wich block size. It could be sequential 512B, in wich case 80MB/s isn't that impressive.

It looks like they are trying to secure Series A venture funding, so unlikely they will appear on the street anytime soon. I’m going to dig around to see what I can find out.
On the technical page they compare 35,000 RD/3,300 WR (SSD) with 160,000 RD/ WR (Hard Rectangular drive) so I’m assuming they are talking about 4k random read/writes. Insane.

there are raid card companies (adaptec and LSI) that are already doing a form of this hybrid, but with arrays. basically they use a single ssd as cache for a HDD array, and the raid controller has intelligent caching that allows for 50x improvement in iops from that array. very smart.

it is called CacheCade from lsi or MaxIQ from adaptec. if they are already doing it for arrays i imagine that it wont be long befor ethey implement it into a single unit.(disk)

Quote:

---

Originally Posted by Computurd

there are raid card companies (adaptec and LSI) that are already doing a form of this hybrid, but with arrays. basically they use a single ssd as cache for a HDD array, and the raid controller has intelligent caching that allows for 50x improvement in iops from that array. very smart.

it is called CacheCade from lsi or MaxIQ from adaptec. if they are already doing it for arrays i imagine that it wont be long befor ethey implement it into a single unit.(disk)

---

:yepp:
Or like Silverstone HDDBoost...

That is exactly what i meant computurd, but my point was doing it for SINGLE DISK. To reach lower-cost consumer markets.
When you do it for arrays, it's called ASAP (Auto-tuning SSD Accelerated Pools of storage). These have been around for over a year now in Rack-mount, and Adaptec started for single-card sollutions this fall.
The problem with Adaptec's method is that they charge like $1000 for a 32GB x25-E for the read-cache, whitout doing anything other than adding a tag to the firmware to show it's their proprietary design. If they would allow using any MLC SSD, it would be a good value-proposition for consumers also, for the time being though, it's only feasable for high-end workstations and low-end servers.
I would consider using a 32GB Barefoot drive as read-cache for a RAID 5/6 from my Adaptec 5805 if it were possible, but i won't even consider buying a x25-E for 2-3x market price.

If you can implement this type of ASAP in a single drive, it would look like a self-tuning read-cache, and making it with a single NAND chip and making it work internally as i have described with read-access logging and filtering could boost average small block random IOPS by 5-10X for general usage.

EDIT: the term ASAP was coined by storagesearch.com. I just remembered an article they had this fall with a 5-year prediction of the storage market. I thought you would find it interresting, but didn't know where to post it, so i just pust it here: http://www.storagesearch.com/5year-2009.html

interesting article, good reading!

Quote:

---

Originally Posted by GullLars

That is exactly what i meant computurd, but my point was doing it for SINGLE DISK. To reach lower-cost consumer markets.
When you do it for arrays, it's called ASAP (Auto-tuning SSD Accelerated Pools of storage). These have been around for over a year now in Rack-mount, and Adaptec started for single-card sollutions this fall.
The problem with Adaptec's method is that they charge like $1000 for a 32GB x25-E for the read-cache, whitout doing anything other than adding a tag to the firmware to show it's their proprietary design. If they would allow using any MLC SSD, it would be a good value-proposition for consumers also, for the time being though, it's only feasable for high-end workstations and low-end servers.
I would consider using a 32GB Barefoot drive as read-cache for a RAID 5/6 from my Adaptec 5805 if it were possible, but i won't even consider buying a x25-E for 2-3x market price.

If you can implement this type of ASAP in a single drive, it would look like a self-tuning read-cache, and making it with a single NAND chip and making it work internally as i have described with read-access logging and filtering could boost average small block random IOPS by 5-10X for general usage.

EDIT: the term ASAP was coined by storagesearch.com. I just remembered an article they had this fall with a 5-year prediction of the storage market. I thought you would find it interresting, but didn't know where to post it, so i just pust it here: http://www.storagesearch.com/5year-2009.html

---

Gullars -
can u say why u'r so occupied with that speeding issue?
why do u need SUCH speedy drives and what are u going to use them for which demand such speeds?
i find it hard to understand what people are doing with a 1900MBps sequential disk array as Tiltervos, or mbreslin using something like this as well,
steve is using his array for benching, which is understandable, yet why does any "regular" - non enterprise user needs SUCH throughput is something which is quite misunderstood.

p.s - the HRD is probably tested on 4KB blocks,
usually drives are being benched @ this scale random,
it's a kind of a convention - standard.

I know, the consensus on using IOPS whitout any other marking is 4KB random. However there are some cases where people deviate from this whitout specifying, and when i see numbers that seems a bit extreme, i always want to make sure.

The speed i'm talking about in this thought experiment is simply accelerating IOPS from average harddrives, and possibly also a bit bandwith bump.
It will be like making a harddisk perform like a low-end SSD for cache-hits, wich would have a high percentage with a 4-8GB cache for average usage. And with only a $10-20 price increase.

Another point i'm making is completely unrelated to performance. Using such a cache would significantly reduce head-thrashing from random reads, and thereby reduce power consumption, heat generation, noise levels, and wear on the drive. You could also get the same real-life performance from a slower spinning drive and slower reacting read/write-head, requireing less power and lowering production costs.
Using a bit more sophisticated caching function (with custom driver), you could let the drive spin down completely more often, or possibly have a lower spin state (f.ex. 1000RPM) and have the file structure and metadata in the cache so the drive only would need to spin up for accessing un-cached files (or large files in the case of 1000RPM slow-spin state).
Either type of caching could be justified price-wise simply from power-savings and extended life. The added performance wouldn't hurt either :P


With regards to 1000MB/s+ bandwidth, most people won't need it. Those who need it will be power-users in their workstations. F.ex. VMware, databases, working on large volumes of files, servers, etc.
Most people would hit the point of diminishing returns around 500MB/s bandwith (both read and write) and 50K IOPS. This can be done with 2-3 SSDs in RAID-0 from ICH10R.

well, it sounds reasonable, i'm just wondering whether manufacturers havn't thought yet about this solution, as u can seemingly increase an HDD performance with a caching function.
raid cards has been using it, Intel has suggested it with it's braidwood technology, so it only raises the question, why does HDD manufacturers indeed havn't been using it yet, and especially for the server market, where drive longevity or MTBF is much more important.

E:
i've been going over the thread :lol:,
it seems, as mr. anvil has showed, they had thought about it,
it could be that high NAND prices has sabotaged this direction in the past, and manufacturers desire for a wider SSD market adoption, has lay this idea into a hold.
from that perspective, generally, adding flash chips to HDD architecture should lower flash prices as more of it would be produced, what would eventually enable an SSD prices drop and streaming it more and more into mainstream usage.

i'm not sure they won't be using it though, as flash prices do get down, and there's a constant ungapping which needs to be maintained between HDD market and the SSD one,
both from a capacity aspect and customers awareness to it,
it seems only as the companies interest to allow such option.
with global worming and cutting down electricity bills and power usage,
such an hybrid function sounds like the thing that might bridge between these two ends and bring about an intermittent solution.

maybe we should talk with them?
what do u say?

E2:
have a look at this, it's basically the same idea
seagate hybrid drive

E3:
u may want to read about some of it's drawbacks here:
wiki - hybrid drive drawbacks.
just for noting it,
i don't think manufacturers aren't thinking of these solutions, yet as we all probably know, technological implementation is never as simple and strait forward as it seems on paper,
this is a great deal of part of the research, this is where we're learning of our misunderstandings and thinking mistakes,
but maybe we should indeed forward these questions to a HDD manufacturer, and see where the difficulties are,
for us users, it is relatively easy bringing up idea's when they cannot be all-the-time accepted,
the main difference is we usually are never aware at all the deficits,
this is really the breaking point where we would HAVE to discuss this with someone who is further aware of it.

I see you say you have read (or skimmed) the thread, but you still bring up points already addressed.

To adress E2, it's basically the same as Samsungs hybrid drive. It uses a small (<1GB) flash cache, and relies on the OS to make use of it. This is NOT the type of caching i'm talking about here.
To explicitly underline it again, the sollution i'm talking about is a rather large cache (0,5-1%+ of drive capacity, 4GB+) and managed internally by the harddrive controller as a read-cache whitout the OS ever knowing it's anything other than a normal HDD. This ensures it's completely compatible with any OS and computer supporting a standard SATA HDD.


To address the counterpoints in E3:
First off, what's addressed in this thread is a HDD with a flash read-cache, not a hybrid drive. You could call it that, but it would identify itself as a normal HDD and act as one, just with ~5K IOPS from cache hits.

To take it point by point:

Quote:

---

Lower performance (access time) for non-cached data
If the data being accessed is not in the cache and the drive has spun down, access time will be greatly increased since the platters will need to spin-up.

---

Sure, cache miss = HDD speed, cache hit = low-end SSD speed. Hitrate for files <1MB would likely be ~80-90%, <128KB closer to 95-99%. Overall speed = faster than 15K SAS for average usage and really "snappy" if the usage pattern has a lot of hotfiles.

Quote:

---

Lower performance for small disk writes
Flash memory is significantly slower for writing small data, an effect that is amplified by use of journaling file systems.[9]

---

Could be true for a hybrid drive, but not for this type of read-cache only use. Random writes would be equal to a HDD.

Quote:

---

Increased cost
Hybrid hard drives are currently more expensive than their non-hybrid counterparts, because of the higher cost of flash memory.[9]

---

At roughly $2,5-3 pr GB for fast flash, a 8GB cache would cost about $20, wich would easily be justified for high-performance drives from the added IOPS, and for large capacity (1TB+) "green" drives from power savings combined with fast hot-file access.

Quote:

---

Reduced lifetime
A hard drive, once spinning, suffers almost no wear. A significant proportion of wear arises during the spin-up and spin-down processes.[8] Indeed, the number of spin-ups is often given as the indication of the lifetime of a hard drive.
Flash memory allows far fewer write cycles than a hard disk

---

Spin-up and spin-down COULD be an issue if it's very aggressive. For high-performance drives with the kind of cache in question here, spin-down would not be an issue as it wouldn't happen. For "green" drives, it could be an issue, but not more than normal "green" drives if the spin-down parameters are the same.
As for flash memory and write cycles, a read-cache would not likely be completely overwritten 5000-10000 times in a drives lifecycle.

Quote:

---

Increased perceived noise production
A hybrid hard drive, spinning up and down, may make drive noise more noticeable, especially with varying usage conditions (i.e., fans and hard drive spinning up on usage).

---

Like i said for the point above, high performance drives wouldn't spin down, but get noise reduction from reduced head-thrashing. Green drives would not spin up and down more than normal green drives, but could be made more silent by using a slower head servo and still get the same average (or even higher) IOPS performance.

Quote:

---

Increased power usage with spin-ups
A hybrid drive requires spin-up and spin-down more often than a normal hard drive, which is often spinning constantly. Hard drives also draw more power during spin-up.[8][11]

---

Same as the two points above. Not appliccable for high-performance drives, not more of an issue for green versions than normal green versions. Pluss, the max wattage to a single flash chip is below 500µW, or half a watt, average power draw while reading is in the area of 100µW.

Quote:

---

Lower recoverability
Hybrid hard drives, based on storage to both a flash component and a hard drive component, and bound to use by a specific OS (i.e., Windows Vista), cannot be recovered after failure using classic hard drive recovery services.

---

An issue for hybrid drives that require OS support, the sollution in question here is done in-drive and os-independent. Since the flash is read-only cache, there is no more danger of dataloss than a classic hard drive, if anything, a better chance of recovering data in the case of a head-crash since hotfiles would be in the flash and would survive.


I'm in for taking this up with manufacturers, it's just a question who to contact, and how. If anyone on the forum know someone working for a HDD manufacturer, and could get them in here to brainstorm a bit and deliver some respons to the issues we raise, while not advertising their brand or other forum-illegal activities, it would be nice.


EDIT: I'm sure manufacturers, or their storage labrats think of hybrid drives from time to time, or the possibility of flash as a cache, but do not put it past "crazy enthusiasts" to come up with unusual but interresting stuff they haven't thought about.

o.k,
i'm a bit hard with this, i'm still don't have a full grip of the technology,
i skimmed over the thread again, trying to see where i did come over already addressed points, and couldn't find any :shrug:,
i was indeed just trying to strengthen some points, and 'calm' others,
i was trying to oppose anvil's skeptical saying of whether they'll be doing it or not, and maybe i should've quoted it to direct u, but i thought it can generally be understood.
i think it is an option, and that's why i'm saying we should ask a manufacturer of whether this is viable,
yet i'm always coming back to this wall, which is saying, we can't really know..., unless we talk to someone, unless we ask them,
and we'll go circling ourselfs as long as we don't speak to one, so this seems a bit meaningless, if u understand the point.
i tend to think manufacturers are quite aware at strains which are usually unseen by customers,
that's about it, yet it is interesting and surely worth to take the shot.

the only thing i'm missing here is the spin down issue & power consumption,
if there are many hot-files in he workload, there isn't seem to be any reason for the drive to be spinning,
constant spin equals more power draw.

a drive as such, should be much less bound to failure, if u'r referring a non-spinning-down situation, then u seem to be referring to a drive that relies on cache-hits when the heads are being used just when data isn't written already inside the cache.
another point to notice, is the fact that system which needs hi-capacity drives, usually needs them to use the entire space of the drive, which means a great deal of random seeks where the cache counts for less effectiveness.
for a small drive -let's say- 128GB, to have a 4-8GB read cache sounds more reasonable from that perspective,
also, it depends on the work habits of that server or setup, maybe a file server which needs files from different sectors constantly, won't benefit any of this,
and actually, what we're talking about here IS hi-capacity drive dedicated for such setups.

or either u talk about hot-files as system files which are being access repeatedly, so what we're talking about, is a sort of a OS-enhancing disk.

The idea was the simplest implementation is read-caching of hotfiles, ie the most read LBAs on the drive, pluss possibly an algorithm/filter that prioritize LBAs read alone, or in only small clusters at a time (say 4-64KB). This would benefit any workload that has hot files, or hot parts of files, since would simply cache the most requested data blocks of <64KB. A drive used for serving purely video content would likely not get noticable performance boost, but f.ex. a drive serving both video and other mixed files wich are read more frequently would benefit for those. If the usage was OS or app disk, a hot-file (hot LBAs, single to 16 adjacent) caching system of 8GB capacity would likely give a good average hitrate for random small block reads, at least after some time of use.

do you have any idea of work load usage patterns in regard to file size and/or preferred block size for a raid array of different setups?

E:
found something on AT,
light workload -

Quote:

---

The light workload is composed of 37,501 reads and 20,268 writes. Over 30% of the IOs are 4KB, 11% are 16KB, 22% are 32KB and approximately 13% are 64KB in size. Less than 30% of the operations are absolutely sequential in nature. Average queue depth is 6.09 IOs.

---

heavy workload -

Quote:

---

consists of 128,895 read operations and 72,411 write operations. Roughly 44% of all IOs were sequential. Approximately 30% of all accesses were 4KB in size, 12% were 16KB in size, 14% were 32KB and 20% were 64KB. Average queue depth was 3.59.

---

gaming workload -

Quote:

---

gaming workload is made up of 75,206 read operations and only 4,592 write operations. Only 20% of the accesses are 4KB in size, nearly 40% are 64KB and 20% are 32KB. A whopping 69% of the IOs are sequential, meaning this is predominantly a sequential read benchmark. The average queue depth is 7.76 IOs.

---

i've been saying to kevikev member here not long ago that usual QD won't normally pass 10, so it seems right.

now we might be able to get an idea on typical server usage, sadly AT ain't doing any server benchmark with pre-defined work-load for every setup as it does with mainstream patterns,
we'll need to find out the % of hot-files usage in different dedicated machines in order to be able to estimate such "hybrid" feature potential.

iv'e been asking anand few weeks back on the software he uses for he's benches, yet he says it's propriety and NDA'd.
we came up with Xperf from WPT (win performance tool) as a testing tool that might bring out some profound information on disk usage, it's the only one i found, yet havn't had the chance to test it.
darn, i wish i could grab that one he uses, a specialized software that should be especially designed for drive performance analysis.
so much crap in the markets and un-professional tools :mad:,
it seems they don't give independent research any chance.

It's a read-cache i'm discussing in this thread, not a hybrid-drive, that would be an entirely other thing.

As i've stated a few times, the easiest way to implement, and the way i would expect HDD manufacturers to do it, is just adding a single NAND chip and cache the most read LBAs (both over time, and recent) there. It can be done entirely in the drive whitout any difference showing to the OS. Many usage patterns will benefit from such a read-cache, and especially use for OS, programs, or games.

yeah, i mean hybrid, as HDD&SSD/flash conjunction.
it's pretty much hybrid :),
and afaik, usually, hybrid comes as a synonym for joint between two types of technology, or might even imply only a power saving feature, as it has a "green" name.

Then you could call all HDDs hybird platter/RAM since they use 8-64MB RAM cache...
One other point against calling this type of HDD with flash read-cache is ALL data is stored on spinning platters, on a hybrid drive you would have some data stored on flash that's not stored on HDD. That's at least what i think of as a requirement for naming it hybrid.

nvm the naming now,
we're talking about NAND-flash right?
then u don't need a BBU with it and data remain on the cache would still be there in any sudden shutdown.

Seagate seem to have stole your idea.
http://www.fudzilla.com/content/view/18863/1/

If you think about how long it takes to develop, i seriously doubt that :P

I'd like to see 3,5" with 25nm MLC ONFI 2.2 NAND, around 8-16GB of flash for added 20-40$

no :),
of course, was just kidding,
yet your innovation, seems to have been going through seagate (and maybe other companies to come?) engineers heads :)!

as for the drives,
4GB SLC for a start, isn't that bad..
lets wait and see how well it operates compared to the normal ones and the velociraptor or even the SAS's,
if it would take them,
that would be a real winner :up:,
waiting to see also if they used the cache to hold the rotor from spinning - the power consumption for the enterprise uses!

E:
maybe you are right,
maybe an 8GB module would be better,
yet we would have to wait for benches and reviews,
large cache sometimes, can opposite it's original meaning..

I think that the r&D don't make it conceivable. By the time you get the product made and marketed SSD will be so cheap you won't be able to recover your R&D losses for years, if ever. Unfortunately the product wont be $20-30 more for the hard drive. It would be much more expensive because the firmware has to be designed and such. Overall, I think that the reason we don't see it is that hybrids were on the horizon before SSD really started hitting the market. As soon as that happened the projected profit margin dried up. Remember those ANS-9010 and ANS-9010B(The RAM drives). I have 4 of them. It is completely inconceivable to buy them today. The cost to make a 32GB drive is over $1000. Intel SSDs can pretty much match it/beat it on benchmarks, and 32GB is nowhere near that kind of price.

Also, I don't know if it really would improve performance. Having a 4GB cache wouldn't be much better than having a 4GB system cache like Vista/7/Linux use. So while benchmarks for that small portion of the drive would appear faster, real world performance might not improve at all. Also, what market segment would you be looking for. Based on today's prices there's really only 3 markets for hard drive space. Performance, Size, and standard user. The performance group wants only the fastest. Those that want size won't see an appreciable performance increases by adding an 8GB cache to a 2000GB+ hard drive(caching .001% of a drive isn't going to REALLY matter). Standard users won't really care about that cache thing and save their money and just buy that 320GB drive they need even though they'll use 100GB at the most.

So yeah, I think that companies have figured the R&D on a product like this is a dead end.

Edit: Don't get me wrong. I think it would have been interesting to see what kind of caching algorithms would have been invented to sustain this type of product.

8GB/2000GB=0,004, so it could cache 0,4% of the drive, not 0,001%.
Caching 0,5% of a drive COULD matter if those 0,5% were small files read often and in a random pattern, like you'd see on a system drive.
Bump it up to 16GB on a 2000GB drive, and you can cache almost 1%.

For a caching algorithm, you could make it as simple as tracking LBA read and write frequency. LBAs read the most in chucks smaller than 32-128KB would get priority, and also R:W ratio 3:1 or higher as to not wear out the flash.
Since you could write everything in 512KB chucks, and 8-16GB is doable on 1-2 NAND dies (25nm 2-bit MLC), the controller part handeling flash wouldn't need to be that complex.

you got some thoughtful points josh, yet don't forget, prices for a 500GB hybrid drive are about 80$ less from an 80GB X25-m.
with flash prices going down, lars point is coming into the equation where 16GB module can be places with maybe just a small increase in price.

seagate must have used SLC in they're drives in order to prevent fast decay of the NAND.

now 16GB or even 32GB for larger drives could add some speed to a drive, lower power consumption and sustain a longer drive life.

i think this move is more important for enterprise uses, raid arrays, where system ram caching require a lot of memory which most of the time is being used for virtualization.

bottom line is we will have to wait for benches, to see whether this is something relevant or just a marketing buzz/hype.

Quote:

---

Originally Posted by onex

Seagate seem to have stole your idea.

---

The cat is out the bag:

http://www.anandtech.com/show/3734/s...ood-hybrid-hdd

Seagate used a 4GB SLC chip as read-only cache. Exactly what i ranted about, but lower capacity and more expencive flash.
SLC is generaly 2,5x more expencive than MLC pr GB. You could make an 8GB MLC cache at a lower cost, and with only about 20-25% performance impact on both read IOPS and read bandwidth from the chip.
Referance for numbers i will be listing: http://onfi.org/wp-content/uploads/2...bottleneck.pdf
A 8GB MLC package using a 2-plane single die configuration with ONFI 2.1 specs could do about 7500 IOPS and 80-90MB/s seq read. Using 2 such dies in a single package on a single ONFI 2.1 buss would give 16GB, 7500 IOPS and 160-180MB/s seq read. At roughly $2/GB for MLC, $32 for the NAND and say $20 for a single channel simple ONFI 2.1 flash controller, you could get 7500 IOPS and 160-180MB/s for cache hits with a $50 price increase.
IMHO, WD should add such a flash read-cache to their next "Black" drives they launch (and VR if they launch more of them). With a simple LBA read pattern tracking algorithm, R&D shouldn't be that big. Scorpio Black could also benefit greatly from such a 16GB MLC read-cache.
Keep in mind, the 160-180MB/s read from the cache can be done in parallell with max read/write speed to the platters, wich is around 90-100MB/s nowadays for 7200RPM 2,5" drives, so you could get 260-280MB/s peak bandwidth :)

pff,
no,
you won't get 260MBps write bandwidth from such drive,
you have constrains that are not 1 to 1.
if you hook up an SLC and a platter, you would probably suffer from some latency and/or delays,
it is never 1+1 = 2.
like a rookie would say HT would get a bloomfield to operate at 200%.
it doesn't, and it would probably take some time for it to be (and even then probably not 100).
-without being picky on few MBps, yet it is a point which is importaant to keep in mind-.

the engineers over at seagate must have had a good reason to place an SLC cache instead of MLC even though the prices for MLC are higher,
it could be that the reason is, the cache doesn't include all features current SSD controllers has (with trim, GC, write amplification) and so it's life expectancy drops,
it might not even include spare area (though that is quite doubtful), yet, such drive with MLC might lose it's performance after a relatively short usage.

manufacturers are working currently on 100,000 cycle MLC (or have made it all ready), so this idea might be more sensible in time to come.
for two dies, there could be a different controller which can handle both of them in a sort of RAID array,
Crucial C300 are using 2xARM A9 by anandtech,
arm controllers in general should not be too expensive (yet as for the A9's, this is not checked).

placing a SF/marvell/intel/whatever controller in such drive would probably make it much more expensive.
even though the Crucial drive isn't any cheaper.

as for the 16GB cache, it seems a bit too large at the moment, it is almost like creating an SSD out of the drive,
the current momentus, is just a hybrid drive, it is meant for casual users, and not in general for performance,
they can also create a 10K version that would function as the VR, maybe even creat it with smaller platters (like short stroking) for extra speed at the expense of some storage capacity..
they can place a dual 4GB RAM module with a small battery,
they can do many things...

as much as intel can create a 48 cores chip..
yet they are not interested probably,
if they created these drives, with SLC, they must be aware at what they are doing,
they are probably are also aware that MLC function this way and SLC the other in relation to the number of planes and links per die as the Micron PDF shows..

this is they're job, and they know at least a bit of what they are doing,
if there was a guy working at seagate coming to the forum and saying that this is the speediest solution, it could be, that it could be argued...

as yet as long as you don't have a lab and you are testing these things, it is like saying, intel should bloat it's L1 and L2's and add 2 QPI's links, enlarge they're processor to double the die size, in order to place more cores in it etc. etc.,
yes,
it would be speedier, yes, it could be possible that it would work,
yet this is just simple math,
as you probably know already,
it is never linear with computers, everything makes a difference,
a certain controller could work this way, and the other the other,
a company has to test everything from every angle and aspect before releasing it..,
telling them,
"look, you should do this and that", is superflous, with no offense my friend,
as users,
we generally don't know even 30% of what they are doing...

Quote:

---

Originally Posted by onex

pff,
no,
you won't get 260MBps write bandwidth from such drive,
you have constrains that are not 1 to 1.

---

Pleese quote me where i said 260MB/s write bandwidth.
I said 160-180MB/s sequential read from flash, + 90-100MB/s platter throughput (either read or write) = 250-280MB/s total throughput. That may be up to 100MB/s write and 180MB/s read in mixed sequential read/write where reads are purely from cache and write go to platter. You can also get 100MB/s read from platter + 180MB/s read from cache at the same time.

Quote:

---

if you hook up an SLC and a platter, you would probably suffer from some latency and/or delays,
it is never 1+1 = 2.

---

Yes, there will be some latency from checking the cache table, likely in the order of single to low double digit µs. That's significantly lower than flash accesstime.

Quote:

---

the engineers over at seagate must have had a good reason to place an SLC cache instead of MLC even though the prices for MLC are higher,

---

MLC is cheaper, SLC is more expensive.
The reasons for using SLC are:
10x more write cycles, wich allows way more aggressive caching. Usefull if hotfiles are overwritten often or take up much more space than the cache and must be cycled.
20-25% higher read performance, both accesstime and bandwidth
Generally higher binned parts.

Quote:

---

it could be that the reason is, the cache doesn't include all features current SSD controllers has (with trim, GC, write amplification) and so it's life expectancy drops,
it might not even include spare area (though that is quite doubtful), yet, such drive with MLC might lose it's performance after a relatively short usage.
<...>
for two dies, there could be a different controller which can handle both of them in a sort of RAID array

---

No need for any such things in a read-only cache. The controller can write to it in MB size sequential blocks if it wants to, a basic wear leveling algorithm will do. Write performance will not be very important for such a cache.
Two dies in one TSOP (typical flash package) on the same Flash bus does not require any form for RAID, the ONFI specification allows interleaving. Making a controller able to handle <180MB/s, minimal ECC and wear leveling, no random writes, and only one channel should not be a huge undertaking and does not warrant an expencive or complex controller. You could almost make a more powerfull memory-stick controller.

Quote:

---

as for the 16GB cache, it seems a bit too large at the moment, it is almost like creating an SSD out of the drive

---

16GB cache on a 500GB drive makes 3,2% of total drive volume. Meaning you could cache about 3% of the drive. 4GB is 0,8% of the drive.
There is a significant benefit to be able to cache 3% instead of 0,8%. Since you can fit a lot more in the cache, you don't need to be so aggressive with replacing data, and it's great if you have a larger set of hotfiles.

Quote:

---

as much as intel can create a 48 cores chip..
yet they are not interested probably,
if they created these drives, with SLC, they must be aware at what they are doing,
<rant>
we generally don't know even 30% of what they are doing...

---

I don't see what this part has to do with anything, but i thought i'd reply to it too. The basic concepts of making a NAND flash readcache, and the implications of size and SLC vs MLC can in no way be compared to the other stuff in this part of your post. The idea and how it works is pretty straight forward if you are familiar with read caches on RAID controllers, and the concept of memory tiering.

sorry,
been confusing cache and buffer operation,
SLC of course cost much more then MLC and you 260MBps write is overestimated.

Quote:

---

Pleese quote me where i said 260MB/s write bandwidth.

---

the write numbers aren't that important, the important part is that you seem to take things obvious and as if they are easy to implement,
there is a possibility that manufacturers havn't thought about this idea (doubtfully), yet as a fact,
this cache HDD build have passed through they're minds at least few months or even a year back.

Quote:

---

Yes, there will be some latency from checking the cache table, likely in the order of single to low double digit µs. That's significantly lower than flash accesstime.

---

yes,
MLC and SLC should not have any difference from the controller aspect, latency should be less and so it's way of operation with it's constrains, yet,
it easy to give idea's (not that it is bad), yet without actually testing them, these are only words which is not much..,
there is no word on seagate trying MLC for they're hybrid drive (in the end, it is called hybrid..:gotcha:) and if they havn't tried it and rejected it, and so it's hard to tell the overall function of the drive,
i think your approach is saying "they don't know what they are doing" which cannot be said without testing.

Quote:

---

10x more write cycles, wich allows way more aggressive caching.

---

o.k, said that...,

Quote:

---

20-25% higher read performance, both accesstime and bandwidth

---

o.k,
we just don't know if it is the performance which made them decide on SLC for the cache function,
could be both,
if it is performance, then MLC could be not fast enough,
i think it has to do with the write cycle and the performance is just a beneficial adder to that..,
but really, i don't know.

Quote:

---

Two dies in one TSOP (typical flash package) on the same Flash bus does not require any form for RAID,

---

talking two dies, separate,
it could be asking for a different controller then they are currently using,
yet, i don't know how many channels they're controller can take and why would they be using a dual channel controller for a single channel operation.
if there are any single channel controllers at all and they are not coming standard with few channel option...

aside from that,
you say they work with internal write buffer so the cache is written too much less (bigger blocks),
this also includes write amplification, and 4GB is a small area to manipulate,
not much spare area left, -must be some spare pool for bad sectors replacement-
the cache should be written to more times then any disk, any frequent read operation is being written, so probably that is the necessity for SLC.

Quote:

---

16GB cache on a 500GB drive makes 3,2% of total drive volume. Meaning you could cache about 3% of the drive. 4GB is 0,8% of the drive.
There is a significant benefit to be able to cache 3% instead of 0,8%. Since you can fit a lot more in the cache, you don't need to be so aggressive with replacing data, and it's great if you have a larger set of hotfiles.

---

yeah, no doubt it relieve some issues yet it would make it more vulnerable to decay,
MLC is still MLC, and as long as they do not take 100K write cycles, placing it withing a read cache is not wise.
these drives should work up to 3 years and maybe more for enterprise.

Quote:

---

I don't see what this part has to do with anything,

---

this part is saying, you are bringing up an idea, in a way, that is saying, "hey, you missed that spot",
well, how do you know?
how do you know they havn't been thinking about that?
you come self assure and seem even to underestimate these engineers understanding.
it is not a rant at all, just explaining,
it is the same as an enthusiast would come at the intel CPU forum and say "why don't you add more cache? why don't you add more die space? etc. etc."
i'm saying,
these guys know what they are doing, and part of they're decisions lay on the market adoption of they're product, the market financial status, they're competition with other companies, the life longevity of they're products,
a road map for future drive and development,
not just to make some enthusiast happy.
we generally don't know even 30% of what they are doing....

sorry,
been confusing cache and buffer operation,
SLC of course cost much more then MLC and you 260MBps write is overestimated.

Quote:

---

Pleese quote me where i said 260MB/s write bandwidth.

---

the write numbers aren't that important, the important part is that you seem to take things obvious and as if they are easy to implement,
there is a possibility that manufacturers havn't thought about this idea (doubtfully), yet as a fact,
this cache HDD build have passed through they're minds at least few months or even a year back.

Quote:

---

Yes, there will be some latency from checking the cache table, likely in the order of single to low double digit µs. That's significantly lower than flash accesstime.

---

yes,
MLC and SLC should not have any difference from the controller aspect, latency should be less and so it's way of operation with it's constrains, yet,
it easy to give idea's (not that it is bad), yet without actually testing them, these are only words which is not much..,
there is no word on seagate trying MLC for they're hybrid drive (in the end, it is called hybrid..:gotcha: ) and if they havn't tried it and rejected it, and so it's hard to tell the overall function of the drive,
i think your approach is saying "they don't know what they are doing" which cannot be said without testing.

Quote:

---

10x more write cycles, wich allows way more aggressive caching.

---

o.k, said that...,

Quote:

---

20-25% higher read performance, both accesstime and bandwidth

---

o.k,
we just don't know if it is the performance which made them decide on SLC for the cache function,
could be both,
if it is performance, then MLC could be not fast enough,
i think it has to do with the write cycle and the performance is just a beneficial adder to that..,
but really, i don't know.

Quote:

---

Two dies in one TSOP (typical flash package) on the same Flash bus does not require any form for RAID,

---

talking two dies, separate,
it could be asking for a different controller then they are currently using,
yet, i don't know how many channels they're controller can take and why would they be using a dual channel controller for a single channel operation.
if there are any single channel controllers at all and they are not coming standard with few channel option...

aside from that,
you say they work with internal write buffer so the cache isn't been written too much less (bigger blocks),
this also includes write amplification, and 4GB is a small area to manipulate,
not much spare area left, -must be some spare pool for bad sectors replacement-
the cache should be written to more times then any disk, any frequent read operation is being written, so probably that is the necessity for SLC.

Quote:

---

16GB cache on a 500GB drive makes 3,2% of total drive volume. Meaning you could cache about 3% of the drive. 4GB is 0,8% of the drive.
There is a significant benefit to be able to cache 3% instead of 0,8%. Since you can fit a lot more in the cache, you don't need to be so aggressive with replacing data, and it's great if you have a larger set of hotfiles.

---

yeah, no doubt it relieve some issues yet it would make it more vulnerable to decay,
MLC is still MLC, and as long as they do not take 100K write cycles, placing it withing a read cache is not wise.
these drives should work up to 3 years and maybe more for enterprise.

Quote:

---

I don't see what this part has to do with anything,

---

this part is saying, you are bringing up an idea, in a way, that is saying, "hey, you missed that spot",
well, how do you know?
how do you know they havn't been thinking about that?
you come self assure and seem even to underestimate these engineers understanding.
it is not a rant at all, just explaining,
it is the same as an enthusiast would come at the intel CPU forum and say "why don't you add more cache? why don't you add more die space? etc. etc."
i'm saying,
these guys know what they are doing, and part of they're decisions lay on the market adoption of they're product, the market financial status, they're competition with other companies, the life longevity of they're products,
a road map for future drive and development,
not just to make some enthusiast happy.
i'm saying,
we generally don't know even 30% of what they are doing...

Hey, that Seagate Momentus XT 500GB is looking good right about now! An affordable alternative to pure SSD has arrived. A good looking upgrade from a pair of 7200.10 Barracuda's. :clap:

Quote:

---

Originally Posted by GullLars

So, lately i've been skimming through a few old articles and papers on HDD/RAM and newer Flash/RAM hybrid drives. After looking at the specs and contemplating architecture a bit, i was left with a question:
Why hasn't any HDD maker yet added a flash read-cache?

By adding a single 4-8GB MLC NAND chip, costing roughly $2-3/GB = $8-24 added cost, and using it for read-caching hot-files, you can get around 4-5000 4KB random read IOPS = 16-20MB/s (@QD 1) and roughly 40-60MB/s sequential read for the cached data. And since it's a read-cache, write speeds and write cycles will be largely irrelevant.

Tracking hot-files should be easy to implement simply by logging read-access to LBAs, and with a slight bit more effort, filtering LBAs being read in a small block random pattern. Possibly also caching file-table and folder/file structure and metadata, as well as the data typically read the first seconds after power-up or spin-up. This could allow low-power "green" drives to not spin up everytime you access it if you don't need un-cached data, and could also allow the drive to spin at a lower speed while delivering adequite performance. Lower rotational speed could also allow higher storage density.

Using this type of caching would have a noticable effect on typical usage patterns, and especially multi-tasking, but would likely not make an impact on benchmarking since it would take some time for new data to reach cache.

Larger hot-files could benefit from the cache as they could be read from both flash and disk at the same time with the speed of both combined (80-140 + 40-60).

With a custom driver (or a mini-USB port?) you could also have a tool-box to allow advanced users to manipulate the cache. Filtering by filetype, file size, heat (frequency of access, both short-term and long-term), location, etc.

The failure of a cache of this kind is not (or does not have to be) fatal for stored data or even function of the HDD.


Any thoughts people?
Does this sound doable, and if so, to what extent?
What kind of drives would benefit the most and be acceptable with a bit higher price and performance?
Would HDD makers consider this or do this if it was doable and there was a market?
(I think it's doable at least with simple LBA access frequency logging, and there being a market in almost all segments, however niche in some)

---

get this is you don't want to get SSD

http://translate.google.com/translat...irasawa002.htm

http://www.geekstuff4u.com/3-5-diy-ssd.html

http://www.techpowerup.com/75490/Sha...S_DIY_SSD.html

Quote:

---

Testing with HD-Tune, six 8GB SDHC memory cards with Class 6 speed ratings had a read speed of 140 MB/s and a write speed of 115 MB/s.

---

Intel X-25E SSDSA2SH032G1 (32GB,64GB) is Read 250MB/s, Write 170MB/s

http://www.techpowerup.com/img/08-11-05/112b.jpg
http://www.techpowerup.com/img/08-11-05/112c.jpg

I just read the review on Tom's Hardware about the Seagate Hybrid drive. http://www.tomshardware.com/reviews/...-ssd,2638.html

Overall, I am not particularly impressed. I still think that my original assessment that determine what to cache, when to cache it, etc makes hybrid drives not a significant player. There's a few benchmarks that are worse (like seek times, wtf?!) and others that are slightly better. I also think that benchmarks are going to prove completely useless for a design such as this. You have RAM cache, you have disk cache, and now you have the flash cache? If you are on a RAID controller you have the controller's cache too. How many "levels" do we want to have? Quite frankly, I'm sure there's duplicates between all of those cache levels, and somewhere someone is going to realize that we have diminishing returns on cache. CPUs have L1, L2, and some L3 cache. I have yet to see a review of L4 cache. Why? Because diminishing returns start playing a larger factor and the cost does not result in an appreciable performance benefit.

But, who am I to argue with it? If anyone thinks these are a great buy, feel free to buy one. I hope they provide the performance you want, and the reliability you hope for. I'll save my money for the real SSD.

If you have the money and the possibility to run SSD for OS + apps, and HDD for the rest, that's a clearly better sollution.
The Toms Hardware review focuses on synthetic testing with big testfiles, so i'm not surprised there wasn't much performance gains to be meassured.
If you check Anand's review, he found it was faster than a velociraptor in many real world tests, like opening apps and booting.


@onex: I'm not saying seagates engineers have made a mistake, or that they should fix something. I'm talking about an alternative approach, where you have a larger and less aggressive cache. If you set it up to be not so aggressive, the lifetime of MLC should not be an issue.
Maybe Seagate found that a smaller aggressive cache worked better for their targeted market segment, i don't know. I suspect strongly a bigger less aggressive cache is more benificial as the only drive in a laptop.
The flash controller would only have to be 1 channel, the two dies can share a channel in serial configuration, and since you can get two dies in one package, the physical footprint is the same.


@serpentarius: I've seen that sollution before, over a year ago. The performance is worse than the lowest end Indilinx Barefoot drives, or JMF612. Modern SSDs easily do 200MB/s read, 100MB/s+ write, 5000-30000IOPS (20-120MB/s 4KB random, that's 4-24 times higher than the numbers you link to). The cost of the drive + SDHC cards also becomes higher than MLC drives pr GB.
It's a fun product, but it's not good for performance.

I have that product. It sucks, bad. I tried to install Windows XP Home. 2 hours into the installation I turned the laptop off. Later I did decide to install windows just to see how slow it would be. It had 2-3 minute boot times with no other software installed. Overall, it would make a good drive to put games on or as a backup drive, but little else. Definitely not as a boot drive. I wouldn't recommend anyone purchase that drive because the cost just doesn't justify it.

Quote:

---

I'd like to see 3,5" with 25nm MLC ONFI 2.2 NAND, around 8-16GB of flash for added 20-40$

---

I've been trying to get more information to the ONFI Specs for some time now, especially regarding the performance. I found whitepapers, but is there some short list where I can read more about the specs regarding performance of the different ONFI versions?


OT:

4GB-8GB Cache is enough IMHO. If you check your file sizes: on 4GB, you can get every file up to 256kb on a desktop windows installation with many installed programs. The performance boost caching bigger files than that should be minimal.

Quote:

---

I've been trying to get more information to the ONFI Specs for some time now, especially regarding the performance. I found whitepapers, but is there some short list where I can read more about the specs regarding performance of the different ONFI versions?

---

you can try they're site.

Quote:

---

@onex: I'm not saying seagates engineers have made a mistake, or that they should fix something. I'm talking about an alternative approach, where you have a larger and less aggressive cache. If you set it up to be not so aggressive, the lifetime of MLC should not be an issue.

---

16GB of cache sounds a bit too big, thought it could take some of the work of it,
remember, read cache could have a lot of writes, MLC NAND could be problematic.
RAID controllers are using DRAM memory, due to speed probably and could be from degradation concerns,
even though it has to use a battery backup unit which is pricey to keep the data secure.

Quote:

---

and since you can get two dies in one package, the physical footprint is the same.

---

16GB should be 2x8GB packages.

RAID controllers only need BBU if you are using the RAM cache for writes. If you use it as read-only (for hotfiles and read-ahead) you don't need the BBU.

Here is some INFO on ONFI (got you confused there? ;)) http://onfi.org/wp-content/uploads/2...bottleneck.pdf
Since these are the most recent and accurate numbers i have on ONFI 2.x performance, i've been using them. Pleese give me references to newer numbers if you stumble upon some.


Advantages of using RAM over flash for caching:
-unlimited write durability allows use as write-cache, provided a BBU
-lower latency (up to 100x+ lower)
-higher bandwidth (a single DDR2 800mhz DIMM can do 6,4GB/s, close to saturating PCIe 2.0 x16)

Advantages of using NAND flash for caching:
-way lower cost
-much higher capacity density
-lower power
-"good enough" read latency to remove/elleviate IO-bottleneck (~50µs access, 5000-10000 IOPS), and enough read bandwidth to saturate SATA/SAS interfaces with a handfull of dies (80-120MB/s pr die).
-non-volatile, data stays in cache whitout power

Short summary: If you need write caching, RAM is your friend. If you need high density and can make due with read-only and use a SATA/SAS interface, NAND provides value.

@Eggcake, i'm well aware of the ammount of small files on a typical windows installation, if you skim through my rants on the first page, you'll se i've discussed it. 4GB should hold most small files on a typical computer, however, you need to update the cache when the files are overwritten.
On a typical computer, you'll have a good amount of over-writes of small files, wich would lead to a lot of writes to the cache. By making the cache 2-3 sizes of the small files, you can have multiple versions (all but 1 outdated) of the same hot files before you need to flush the old invalid ones. If you have 4GB of files below 128Kb, and 10% of them are overwritten every week (400MB writes pr week), where 10% of those again being overwritten 10 times every day (+400MB writes pr day), the 12GB of extra space will give you a month before you need to flush invalid files, at wich point you will have large blocks you can clean effectively.
You could also have the drive run boot-traces, like the drive logging all LBAs read the minute after it's turned on. After a few times, you will have some LBAs that are read most times, and the order they are read. By arranging it sequentially in the flash cache, you could get 150MB/s+ during start-up for common files.

Quote:

---

RAID controllers only need BBU if you are using the RAM cache for writes. If you use it as read-only (for hotfiles and read-ahead) you don't need the BBU.

---

you are right at this one (overlooked it),
nice.

Quote:

---

Pleese give me references to newer numbers if you stumble upon some.

---

already gave you this one :),
it should be enough for now,
it seems to be the last document currently.

Micron has some fabulous documents and technical notes, worth taking a look at :yepp:.

IM joint venture 25nm NAND should take die sizes even less then the current (read somewhere about the actual sizes, yet forgot it),
34nm to 25nm move is not a full node, so it doesn't mean that a 4GB die would get to be 8GB (die, not package), unless they maybe re-size it,
34nm full node move should be 22nm.

apparently, an Intel X25-M 80GB drive has only 10 chips for 80GB capacity, so they should be 8GB each,
strange enough, there are no spare chips for spare area, or rather intel's drive doesn't support that (or rather they are placed at the other side of the PCB (which is not shown through the pictures :)).

the LE (100GB) apparently has 16 packages (each for E:8 (not 16)GB) for a total of 128GB.
pictures.

Quote:

---

The OCZ Vertex 2 Pro features Intel 29F64G08CAMDB MLC flash memory. In total there are 16 chips and each IC is 8GB in density. That adds up to 128GB of storage space, but only 93.1GB of it will be usable space!

---

Afaik it is 80GiB, you only got 74.5GiB formatted space. So in the end you got about 9% spare are on intel drives.

correct eggcake, the spare area is not taken from entire chips (dies), but portions of them reserved.

Intel x25-M 80GB uses 10 channels, with 10 TSOPs (packages), the number of dies may be 2 pr package, meaning 4GB dies, or one die pr package at 8GB.
The x25-M 160GB uses 10 channels with 20 TSOPs, half on each side of the PCB.

Quote:

---

the number of dies may be 2 pr package, meaning 4GB dies, or one die pr package at 8GB.

---

should be 2 dies per package.

http://img576.imageshack.us/img576/7...ercapture1.png
(taken from the Micron PDF).

The 160GB and 80GB look the same, (only 1 side of the pcb is filled up with Flash). The 80GB uses 4GB DualDie Packages, the 160GB uses Quad Die Packages:

http://www.abload.de/img/nfth6vsmzj4r.png

That was when they still planned the Refresh with 34nm :)

( http://www.anandtech.com/show/2808/2 )

Edit: Of course I was and am always talking about the G2! G1 only uses 4GB Packages as far as I know.

hhaa, so the 160GB x25-m uses 4 links per die which is what makes it faster then the dual link 80GB G2.

the X25-E goes with 10xquad 2GB die packages, each for 8GB and another dual one with 4GB, for a total of 84GB (20GB spare area),
and that is what is making it so expensive!

great!

E:
G1 vs G2 160GB:

Quote:

---

More memory means that the drive can track more data and do a better job of keeping itself defragmented and well organized. We see this reflected in the "used" 4KB random write performance, which is around 50% higher than the previous drive.

Intel is now using 16GB flash packages instead of 8GB packages from the original drive. Once 34nm production really ramps up, Intel could outfit the back of the PCB with 10 more chips and deliver a 320GB drive. I wouldn't expect that anytime soon though.

---

the SSD relapse AnandTech!http://e.deviantart.net/emoticons/c/clap2.gif

Quote:

---

Originally Posted by onex

hhaa, so the 160GB x25-m uses 4 links per die which is what makes it faster then the dual link 80GB G2.

---

No, the 160GB uses 4 dies pr link. The exact inverse.
The x25-M has 10 flash channels/busses/links, when there are more dies than channels, then some dies will share a channel in a serial interleaved configuration.

Check out page 21 in this document for some performance illustration: http://onfi.org/wp-content/uploads/2...bottleneck.pdf

This is kinda off topic, but here goes a rant:
If the x25-M G3 uses 10 channels of ONFI 2.1 25nm NAND on ONFI 2.1 busses, the bandwidth and IOPS would be (given the numbers in the previous document) rougly:
Single die packages, 10 packages: 880MB/s read (internal), 80MB/s write, up to 75.000 4KB random read IOPS, up to 20.000 4KB random write IOPS.
Dual die packages, 10 packages: 1760MB/s read (internal), 160MB/s write, <75K IOPS read, <40K IOPS write.
Quad die packages, 10 packages: 2000MB/s read, 320MB/s write, <75K IOPS read, <80K IOPS write.
Quad die backages, 20 packages (double stacked or on both sides of PCB): 2000MB/s read, 640MB/s write, <75K IOPS read, <160K IOPS write.
I'd hope Intel makes a version of G3 SSD, with a PCIe 2.0 x4 interface, 10 channels, dual die packages, 10 packages. Given 8GB dies for 25nm, that would give 160GB. You'd get ~1750MB/s read, 160MB/s write, <75K IOPS read, <40K IOPS write. Pretty sweet if bootable, and probably not too costly to make either.

Quote:

---

No, the 160GB uses 4 dies pr link. The exact inverse.
The x25-M has 10 flash channels/busses/links, when there are more dies than channels, then some dies will share a channel in a serial interleaved configuration.

Check out page 21 in this document for some performance illustration: http://onfi.org/wp-content/uploads/2...bottleneck.pdf

---

the page linked, is for synchronous signaling,

so the X25-m 80GB G2, has a capability of 176MBps per dual die @ a single channel, on a dual plane die
this document is from july 2008 so it could be reflecting current SSD manufacturing process at that time, the G2's should fit into these schemes.

taking 10 channels, the SSD should go for -optimally- 176*10 = 1760MBps.
write throughput should scale - 16MBps per dual die on a dual plane die,
10 channels, equal, 160MBps write.

read..
wait,

http://hardforum.com/showthread.php?p=1034431478
whether it^^ is related to the signaling method,
the X25-m seems to operate better asynchronously.
the asynchronous performance, goes P.11,
400MBps total read and 140MBps write per 10 channels per dual die @ a single channel.

and X25-M's uses ONFI 1.0.

Quote:

---

A Quick Introduction to the ONFI 2 Synchronous
Interface

---

P.14.

sound more reasonable.

p.s - the NAND is working in parallel.

Quote:

---

ba ba ba.. featuring the latest-generation native SATA interface with an advanced architecture employing 10 parallel NAND flash channels...

---

http://www.intel.com/design/flash/na...ream/index.htm

Quote:

---

This is kinda off topic,

---

will you stop stressing youself over this off-topic thing?
it's perfectly fine to share your thought even they are unrelated to the thread :).

Quote:

---

Single die packages

---

should be dual, (but let's see)...

Quote:

---

Single die packages, 10 packages: 880MB/s read (internal), 80MB/s write, up to 75.000 4KB random read IOPS, up to 20.000 4KB random write IOPS.
Dual die packages, 10 packages: 1760MB/s read (internal), 160MB/s write, <75K IOPS read, <40K IOPS write.

---

lol, exactly what is going through one's mind when following that awesome document,
SATA 3 interface, 600MBps available throughtput,
320GB drives, ONFI 2.1, synchronous interface (double bandwidth), la la la la,
they can bring a bomb to the market :YAY:.

If you want proof of the performance being avalible, just check out what fusion-IO did back in 2007-2008 with their ioDrives.
In 2008, you could buy a 80GB SLC SSD with PCIe 1.1 x4 interface able to do: 750MB/s read, 500MB/s write, 100.000 IOPS read, 80.000 IOPS write (the 100K IOPS write was for the 160GB version).
If i don't remember very wrong, the ioDrive uses 12 channels (or was it 24?) in a low latency cluster setup. Simple math says 750/12=62,5 (MB/s pr channel), and 750/24=31,25 (MB/s pr channel). If it used async NAND, it would likely be 24 channels, if it was early sync, it could be 12 channels.
EDIT: the ioXtreme does 700MB/s(+) read from 80GB of MLC.

Anyways, i have written a long discussion about this general subject in norwegian on another forum (about 3000 words i think it was), and i will be posting a dedicated thread to an english version one of the comming days.
I'm contemplating making a "GullLars' SSD rant/discussion thread" for technical discussions and "what if" or "how awesome would *blablabla* be" as a sort of consolidating thread. We've had a simelar thread on the norwegian forum i mentioned for 1,5 years now, and it has over 7500 posts and 290K times read. About 1/3 could be summarized as FAQ QnA's, and about 1/4 is help for deciding what SSD / if to buy SSD. If you go by word count, about 50-60% is technical discussions and rants about tech sites reviews. I'm responsible for about 20-25% of everything written in the thread XD

Quote:

---

If it used async NAND, it would likely be 24 channels, if it was early sync, it could be 12 channels.

---

you don't get it,
ONFI 1, uses asynchronous NAND, ONFI 2, uses synchronous NAND.
asynchronous transmission is slower then synchronous transmission as the signal has to go through a single line while being modulated,
the modulation process means, each byte, word or Dword has to be separated by a signal telling the receiver where the data packet start and end,
the same as it goes for internet protocols.
synchronous transmission is said to be expensive as it is harder to implement,
it involves two lines when the clock signal works on on and data on the other,
a asynchronous transmission is not really asynchronous yet it is called that way, maybe to separate it's naming from synchronous signaling.

so,
synchronous signaling IS faster,
every byte flowing through it means data as an opposite to asynchronous signaling.
kapish ?

i just think you go over some important stuff, not paying attention to it,
it happens,
first, you have to fully figure out what is happening inside a controller or an IC circuit and not think it is easy and you already understand it,
there are many pieces of data which are coming in between,
if you don't understand something, google it, or say,
i don't understand.
and then offer idea's,
it's the same thing which was told you before actually.

I have read several white papers on NAND flash architecture, ONFI specification (PHY included), controller design, signaling, ECC, etc. I feel i understand it well enough to not make huge blunders, but i'm by no means an IT professional or hardware engineer. Since most of the details of the low-level stuff (hardware wise) is not directly relevant to the topic here whitout increasing the complexity by a lot, i felt it was best to keep from going into it here. This is the sort of thing i could discuss in the SSD discussion/rant thread i made though ;)

Epic fail:

http://hardware.slashdot.org/article.../06/02/0156217

Their newer, more expensive hybrid performs more slowly than their older (and cheaper) generation.

I'm shocked I tell you, shocked!

I hope for their current customer's sake that this can be fixed with a firmware update.