back to article 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 …


This topic is closed for new posts.
  1. Pete 2

    Price of RAM? Bzzzzt!

    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.

  2. Anonymous Coward


    Yeah, but Apple will never allow it on the iPad...

    ...oh, THAT Flash


    1. Anonymous Coward


      Just stop it!

      Pleezze, it hutz!

  3. Steven Jones

    Cache life etc.

    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.

  4. LawLessLessLaw

    What goes around

    People are talking like using Flash cache is something new yet such practice has been around since the 1990s HPC / MPP machines.

    Plus la change

  5. frobnicate

    the last minute rule

    With all the due respect to (presumably) late Mr. Gray, that rule only worked in a rather narrow set of configurations. Realistically, servers, especially high end ones, are stuffed with as much memory as fits in them.

  6. Mr Templedene

    Doesn't Flash Memory

    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.

    1. Antony King
      Thumb Down

      Flash life

      Flash is well over 10^6 write cycles now even before write wear levelling. We've found that flash lasts longer than hard disk. Our proxy servers with disks on customer sites generally last about 3 years; we've yet to swap out a unit with a flash card but the oldest is 5 years.

      1. Charles Manning

        Flash life varies greatly

        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.

      2. Charles Manning

        Flash life varies greatly

        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.

  7. Jerry

    video serving?

    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.

  8. MrHorizontal

    ZFS with multiple subsystems then?

    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...

  9. Steve Briggs

    Can you say ssstttttuuuutttttteeerrrrr - I knew you could!

    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.

    The upshot, your mileage may very a lot - YMMVaL

  10. Fred Mbogo
    Thumb Up


    I've heard that this only happens on consumer flash disks. On Enterprise solutions, they are supposed to schedule the TRIM commands during levels of low activity.

    Wiki...I know but it's well written, I think.

    Quality and performance

This topic is closed for new posts.

Biting the hand that feeds IT © 1998–2020