One example from a previous job, these in a Ceph cluster as an origin for a CDN delivering video. We transcode the video to various bit rates and chunk em, then clients request them through CDN, there is not a lot of writing, with some reads when the asset is new, but once it is cached it just basically sits and is idle.
Larger capacity meant we could store more data in a single rack, our limitation for the origin wasn't CPU or bandwidth throughput, it was literally our storage that forced us to keep expanding.
The deployment I did was using 8TB drives. We used HGST with their Helium because of the lesser power draw, allowing us to install more servers in a rack without going over our maximum power draw and heat density for cooling.
It would be interesting if someone offered a similar plan, but priced on energy consumed instead, giving incentive for managed storage arrays that power down drives that idle (for some algorithmically-derived definition of "idle", trading off against projected lifespan of the device due to increased power cycling), and other energy-saving practices. Slices up the granularity of cloud hosting even finer.
You really can't have too much local storage. Price is the only prohibitive factor, though rebuild times are starting to be too.
Another factor to consider is that uplink, if you wanted to store stuff in the cloud, is almost always terribly slow and often capped, plus the cost of storing multiple TBs on any given provider.
the use cases for raid5 have pretty much been replaced with raid6 plus hotspare.
http://www.zdnet.com/article/why-raid-6-stops-working-in-201...
The wise sysadmin mantra of "RAID is not a backup" must be kept in mind at all times.
Unless 3 drive controllers die simultaneously, you can survive finding faults during a full rebuild.
Why is that happening? There's no reason to perform a bunch of writes to those drives.
(Though probably something with checksums instead of naked redundancy.)
Back in the stone age disks were "fast" in random access but they couldn't hold as much as tape could. So to get the storage you had a mix of disk and tape. That started as you had a command you would send to the operator (another historical concept) which was the person who was responsible for 'operating' the computer. That would print a message on a hard copy terminal that would say "Load Tape XYZ on Drive 2" or something similar, the Operator would go to the shelf of tapes, pull out the one that was labeled XYZ and put it on drive 2, "mount it" (which would, on vacuum readers, suck in and tension the tape and read the first block (the label)) and make it available to the operator who could verify it was XYZ and then send pack (again on the console) "tape loaded." Then your batch program would start and you'd get the classic video of a computer with the tape being read in bits and bursts and often another tape being written in bits and bursts.
Computers got bigger (able to process more data) and tape libraries got bigger, one of Sun's big customers was Fingerhut (mail order catalog) in Minnesota and they had a room where there were lots of 'tape operators' and when a customer was on the phone and the operator said "let me bring up your account" it lit a sign in the tape room with the needed tape, someone would jump up and grab it and put it on the nearest tape drive and 'tag' (there was a clock showing time from request to mount) and the tape would identify itself and send the customer record to a disk so that they were "online" and the operator's screen would light up with all the customer details.
IBM and StorageTek made robotic libraries that did the same thing, but without the human in the loop.
Then in the early 2000's NetApp and other storage vendors started offering ATA disk drives (dense, cheap) as storage offerings and slowly, eventually the tape libraries were crushed because this dense storage was more cost effective.
Primary disk storage has now gone over to solid state disks. They have even better random access and generally and do reads at the limits of the interface they are attached to.
But there is still a market for dense, cheap, read mostly data stores. That which used to be tapes, then tape libraries, and now spinning rust in a bath of helium. A typical SATA drive can really only do about 110 "IOPS" per second, in a large part because the mechanics of moving things around is inviolate.
So the use for dense data stores behind a small i/o pipe is read mostly archival and reference data. Oil & Gas sonar dumps, credit card sales transactions, backups of data which is 'live' elsewhere, etc. The role that Tape used to play but no longer does very well.
