Henry Newman's Storage Blog Archives for March 2012

What Happens When Disk Drive Volume Returns to Normal?

There has recently been some discussion that some time late summer or early fall production of disk drives will be back to normal. What does that mean for the industry? Will prices go back to their pre-disaster amounts, or will they drop to where they should have been based on what we normally expect to happen with disk drive prices? Lots of people are asking these questions, as they are now planning their spending for third and fourth quarter this year. So here I go with a prediction on which I have nothing to base, but neither does anyone else, as the flooding was an unprecedented event in technology manufacturing history.

Once production for all vendors gets back to normal, the vendors that have been lacking production capability, and therefore lost market share, will work to gain that market share back. They will do so by cutting prices. The market will have a number of questions about the quality of the products and, needless to say, they should. Often, rapidly ramping production causes quality issues for any product in any market. If the quality meets the market expectation from the big storage buyers, then the price war will be on, with the new players to the market trying to rapidly gain back market share.

I suspect pricing will quickly get close to where it would have been without the flood, but that will take until early 2013 for the volume get great enough and all the buyers to be comfortable enough with the situation. With 4 TB drives on the horizon, it will not take long for the market to right itself and get back on track.

Expect everything, including prices, to be back to normal by January 2013, with prices starting to drop third-quarter 2012.

Labels: HDD, thailand floods

posted by: Henry Newman

Tape Density, LTO and Enterprises

It has been over a year since Oracle announced T10000C, and not many months later IBM announced TS-1140. Both have huge densities over LTO-5. (Uncompressed density of 5TB for T10000C and 4 TB for TS-1140.) LTO-5 is still at 1.5 TB, and LTO-6 is still unannounced as far as I know. My understanding based on official statementsis that LTO-6 will offer a storage capacity of up to 8.0 terabytes compressed, or 3.2 TB native.

Let's assume LTO-6 comes out at 3.2 TB, and let's assume this happens in 2013, as there have been no official announcements about LTO-6 so far in 2012. We can also assume that neither Oracle nor IBM will stand still. For many years, LTO density was greater than enterprise density. This is the first time both enterprise tape vendors have greater density than LTO.

So what does that mean for the LTO format? Before, LTO had a number of advantages over enterprise tape price, density and interoperability. Now, it has two advantages, and part of the price advantage was that since it had greater density it used few slots in the tape library. That part of the price equation has been lost. I know a number of our customers are currently moving to enterprise tape from LTO because of the density improvements and the savings in floor space because fewer library slots are needed.

What is best for you depends on many many factors including, library slots, tapes drives, media and floor space, but it might be time to consider doing a pricing exercise to compare the cost of enterprise tape with LTO. I have been waiting for a press release about LTO-6 for over six months. The longer it takes the more concerned I get.

Labels: Oracle, IBM, tape, LTO

posted by: Henry Newman

In Search of a Storage 'God Box'

There was an interesting article that came out while I was on vacation titled "The God Box: Searching for the Holy Grail Array: Latency killing super spinner

The premise of the article is that someone is going to build a storage array that solves all the world's problems. As Chris says, "server data location, solid state hardware speed, memory access speed virtualisation, and the capacity, sharability and protection capabilities of networked arrays. It's NAND, DAS, SAN and NAS combined; the God storage box -- conceivable but not yet built."

The one critical point Chris leaves out is scalable file system. I think it is great to solve all of the above problems, but a God Box should solve all the problems not just a subset. Scalable I/O depends on scalable storage and a scalable file system. I am not sure if anyone builds this box how it can be used without a file system that scales infinitely. To have that will require a parallel file system, as in a large environment you will need a number of these so called God Boxes for scalable performance.

A number of things are lacking in the whole file system arena. For example if you have storage tiers, how do you pass policy for blocks of storage over SCSI protocol? Answer: you cannot. The topology of a file is just a set of addresses to the allocation map of the file system. File systems must be modified to know what addresses are flash and what address are other tiers of storage. The file system cannot know what God is thinking without being told. Now this God Box might have a file system that I am not aware of, but how does it work and how does it scale? Only for a handful of parallel file systems and scaling metadata is this a huge issue.

Labels: storage array

posted by: Henry Newman

Why Did Red Hat Buy Gluster?

I have been thinking about why Red Hat purchased the Gluster parallel file system in October 2011. Back in December 2003 Red Hat purchased the GFS file system. GFS did not work out that well for Red Hat. It never added many features and it did not provide scaling. GFS is a totally different type of parallel file system than Gluster. Gluster does not support multiple threads opening and writing to the same file, often called N to 1 (1 file with N threads writing).

On the other hand, Gluster is very good at multiple writes to the file system from multiple threads, which is often called N to N (N thread writing to N files). So you might ask what types of applications do that type of I/O. The one that comes to mind, and the one I think drove Red Hat to buy Gluster, is video surveillance.

This is a large and fast growing market where the market demands very low-cost storage and software and a scalable software stack. Take a casino or a city police force. Each camera, and there are hundreds of them, is writing to a different file, but they want all the files in a single namespace. You might say, why not just buy a bit NAS box? Remember, I said they wanted to do this as inexpensively as possible, and they need scalability. NAS boxes generally do not scale linearly as a shared file systems does by adding servers and storage. This video surveillance market is growing fast, and it will continue to grow as more and more cameras are moving to digital online storage, as compared to writing to DVD or tape.

So why did Red Hat buy Gluster? My guess is that Red Hat wants to eventually take on the NAS players in the part of the market.

Labels: Red Hat, Gluster, Gluster Storage Platform, Parallel File System

posted by: Henry Newman

What Happens to Enterprise PCIe SSDs?

Most enterprise applications today require shared storage, given that the applications must fail over to another system in case of server failure. I know some technologies allow a PCIe slot to be extended, so theoretically you could place another PCIe SSD in another server, mirror the SSDs and have the other server sitting there with the SSD in it as a cold standby.

You could also mirror the storage to disk and then reload the SSD on another server, but this works only if you are doing mostly reads and a few writes, given the latency writing to the shared storage. Many applications that run locally but are not mission-critical can be restarted, but how many sites need SSDs for single-server, non-mission critical applications?

I know the Wall Street trading community needs and can afford PCIe SSDs, as can the movie industry. Some environments can ingest servers for Hadoop systems, but from what I have seen, shared storage still dominates the majority of storage being sold. Some have discussed moving the PCIe SSDs from the server to PCIe slots on RAID controllers so the storage is shared. That solves the problem of sharing, but it creates another problem: access performance and latency. Fibre Channel speed is at best 16 Gb/sec or at most 1500 MB/sec; maybe the RAID controller support InfiniBand and FDR is 56 Gb/sec or maybe at most 6.5 GB/sec -- still far slower than a PCIe 3.0 slot, and you have increased latency by using and external channel.

I am just not sure how big the market is for these devices.

Labels: SSD, PCIe, latency, PCIe SSDs

posted by: Henry Newman