HDD cache as fast external memory?
Rayman
Posts: 14,849
I've noticed that most HDDs have ~8 MB or so of buffer RAM...
Could this be used as high speed external RAM?· I think perhaps if you only access a few sectors, you could read and write very fast, although perhaps the first read to a sector would be slow...
I'm mainly interested because I'm hope to playing around with some low cost 1.8" drives soon:
http://forums.parallax.com/showthread.php?p=834619
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
Could this be used as high speed external RAM?· I think perhaps if you only access a few sectors, you could read and write very fast, although perhaps the first read to a sector would be slow...
I'm mainly interested because I'm hope to playing around with some low cost 1.8" drives soon:
http://forums.parallax.com/showthread.php?p=834619
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
I'm not sure exactly what type of cache HDDs use though... If it's write-back, then this scheme could work. If it's write through, then, it won't work so well, except for reading...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
What I don't know is what would happen if you then asked for the same data to be read back. I don't see why the HD couldn't return the data directly from the cache instead of waiting for the platter, if it's smart enough to manage its cache with a least-recently-used page replacement strategy or something like that.
So it might work, if that sort of memory fits some particular project's needs.
By default most drives use write-back cache to try and make up for their abysmal rotational/seek latency. The ATA spec defines a flush command which is specifically to force the contents of the cache onto the platters. This is why you need journal based filesystems and barriers to increase the reliability of standard operating systems (and RAID boards use battery backed up ram for the cache).
If the application depends on write ordering or ensuring the write has flushed it needs to explicitly use an operating system call that will block until the data is confirmed as written (fsync() for example).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm