Flash and the five-minute rule "Flash is a better disk ... and disk is a better tape." So said distinguished Microsoft engineer Jim Gray in 2006. A few years before then he had formulated his famous five-minute rule of thumb, which said that it is better to cache disk-held data in DRAM if it was going to be re-used in five minutes or less. The idea was that …
OK, I just had to do it.
Up into the loft. Pulled out the May 1987 copy of Wireless World (Ok, ok, _Electronics_ and Wireless World). Advertisement from the now long defunct Microkit lists a 1Mbit TC511000 dynamic RAM chip at £32, so multiply up by 8 for 1MByte, or by 9 if you want to be flashy - error corection? who needs it? fro £250-odd per megabyte. You could even get a full PDP-11/73 (with 1MB of RAM) for £4500 in the back of the same mag.
So far as 15 IOPs disks - I don't buy it. At the time I was working for an OEM and our 300MB SCSI drives were 3600RPM, roughly 10mSec access time, so would easily have given you 40 IOs per second.
Too many verifyable hole sin the orginal article to have any credibility.
Postscript: I've long been aware of the "5 minute rule". However, it's incredibly hard to measure the cache life of a piece of data - even using Oracle's extended database stats. In fact pursuant of this rule I've seen mainframe installations where the memory cache was set so large that the time taken to scan it end-to-end was longer than the average seek time to the disk arrarys.
I can't say there's a lot of rational analysis in the 5 mninute rule of thumb issue. Where does this leave the system code on my SSD? That's always being used so is cached in RAM once the machine is powered up but my issue is just how long it takes to boot the machine, start and applications or when several things are running at once (virus scans and so on) that the machine becomes unusable.
No - a better way of working this out is how much time is it costing you to wait for all the I/Os to compete for a given function. If you can't afford (or can't bear to wait) for all the required HDD IOPs then some form of caching is going to be required. Similarly, if ever more complex apps and DBs require access to more and larger lumps of data then quite simply it won't matter if you need that data every 10 seconds or every 10 hours. The transaction time could simply be too long for business purposes.
It's actually possible to do numbers on this - anybody involved with large call centre operations will know that response times matter. They matter because you need more staff, terminals, phone equipment and so on if they are waiting indirectly on HP). Even modest increases in staff costs can swamp hardware and storage costs. Then there is the customer service angle - generall customers for call centres are none to happy having to wait for the service agent's slow computer. The sort of account data will not be in RAM simply because it's rarely accessed - populating all the customer data in the early stages of a call is often the most time consuming part.
Nope, what makes sense is analysing the critical time paths in your application, costing it and adding the other human satisfaction characteristics. That tells you if you need and SSD - not some 5 minute rule-of-thumb.
There is also another issue - the access density capability of HDDs is plummeting (that's IOPs per unit storage) as capacity ramps up. You have to cache more and more to make systems usable.
Have a limited number of read/writes before it dies? I seem to remember the figure of 10,000 approx.
I'm sure in a big, mission critical operation like a call centre this would be reached pretty fast, so a nice turnover of new flash memory would be required, nice little profit stream for someone.
I suppose the payoff between regular payments to replace that, compared to speed increase would have to be worked out.
Some is good for well over 10^6 cycles.
Some is only good for 10^4 or less cycles.
There are a lot of other factors. High and low temperatures cause problems too.
The real cheap stuff is designed for typical camera/mp3 player use. In the lifetime of a typical MP3 player you would not be filling the unit more than a hundred times or so.
If you're using the flash for buffering streaming video etc then that's a completely different matter.
All this caching stuff falls in a might heap when you run a video server.
Any half competent video server will vend 1 Gbps through its ethernet interfaces. That's 125MB/s. That is every 8 seconds you consume a Gigabyte of data.
Caching for 5 minutes? that would be 937 GB - call it a terabyte - to serve 250 clients at standard resolution digital TV.
For a truly Video-on-Demand system, caching means zilch. What counts is the effective transfer rate from the drive array.
Normal videos range from 15 - 200 minutes. The benefit of caching of 1TB for 250 randome access customers is almost, but not quite equal, to zero.
Really this 'insight' is just ZFS but reincarnated with several subsystems working together in a higgledepiggledy way rather than one homogenous technology.
ZFS has it's famous ARC RAM cache. It can then be configured to use 'L2ARC', using the same ARC algorithm on SSD devices, and finally the actual data held on the disks itself. Add in extra features such as RAID-Z eliminating the RAID 5 goal, snapshots and the like, and it's a far, far more elegant solution than this...
Flash is wonderful for write-a-few, read-mostly apps. It's great for storing apps too large to be held in memory with the data they're processing. It is not a one size fits all solution.
Testing in Silicon Valley (not necessarily intended testing either) has shown that once the drive fills up and it's mandatory to erase a block to permit the next write to occur, the huge latency for erase-write causes a stuttering sensation to the user. Fast, slow, fast, slow, fast, fast, fast, slow, slow, throw monitor through wall.
The video on demand example is one of hundreds where the read-mostly scenario is violated.
http://www.theregister.co.uk/Design/graphics/icons/comment/grenade_32.png
The upshot, your mileage may very a lot - YMMVaL
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
