Slashdot Mirror
Getting Rid of the Disks
Kneht writes "Dan's Data has an interesting article on what it would cost to get rid of your HDDs and replace them with SSDs because hard drives suck. Several aspects are examined, such as required UPS, compact flash, etc. Read the article and you may get a new appreciation for your lowly 7200rpm drive."
Funny, I was just thinking that I should start using 120GB disks as my removable media.
Right now, hard drives are the right cost/benefit compromise. Could they be better? Yes. Would it cost a lot more? Yes. When the second changes, let me know.
Get rid of my High Density Diskettes (HDD) and replace them with Single Sided Diskettes (SSD) ???
That would be expensive, because the old drives are expensive when you find them from collectors on eBay, besides which I would have far less storage capacity (180K instead of the 1.44M I have now).
It reminds me of the short period back in the day when I ran my BBS on a three floppy diskette PC system. The third floppy diskette was a 5-1/4" 720K drive (quad density) but users complained about the slowness, and this was 1200 baud users.
There's a lot of research going on in this area. In particular, there's a newly completed Ph.D. thesis studying a persistent memory/disk hybrid filesystem for linux, named conquest. The performance is quite impressive, although the reports are that it's nowhere near ready for use - the term 'researchware' gets tossed around a lot.
Basically, by storing metadata and files smaller than 1mb in memory, the typically accessed information is much more convenient, and the larger files left on the disk are typically in their 'best case' (it's much more common to read large files than to write them, and typically they're read in some near-linear order: if you watch a moving, you may skip once or twice, but then it's sequential reads). The combination seems to work quite well: We compare Conquest's performance to ext2, reiserfs, SGI XFS, and ramfs, using popular benchmarks. Our measurements show that Conquest incurs little overhead compared to ramfs. Compared to disk-based file systems, Conquest achieves 24% to 1900% faster performance for working sets that fit in memory, and 43% to 96% faster performance with working sets larger than the memory size. .
Video for Online Dating Profiles
I'm finding that the lack of a universal DVD standard has left me looking at HDDs as my removeable media of choice as well. CDRs are nice and cheap, but I have files that would span multilpe CDRs. It's a little bit of a hastle to have to WINRAR up my data into small chunks, only to have to UNRAR it back into oen big chunk. DVDs aren't readable everywhere. I'd love to see faster solid state storage available at a price competitive with today's HDDs, but alas, it's just no there. I already have a great deal of respect from my 7200RPM HDDs
There are lies, damned lies, and statistics.
http://ask.slashdot.org/article.pl?sid=0
-- -- --
Help my mini cause: My journal
SSDs are good for research purposes and Software Developer Kits. I think Intel's Explorer 2 SDK used to have 128 MB on board, which is useful for Assembly programming.
I remember when we used to program Motorola 6800... hehe...
Consensus is good, but informed dictatorship is better
I don't understand the hard drive bashing. Sure, it isn't as fast as DDR, but it's faster than any other storage media... It's not only faster, but cheaper as well.
In addition, I've had many power supplies and entire motherboards die in the same period as my hard drives have been operating. The best part of all is that they have very obvious signs when they are beginning to die, as well.
Hard drives are not the fastest or most reliable piece in you computers, but they are definately not the worst or slowest. Who here can find ECC DDR RAM for anywhere near $1/GB?
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
When you look at something like this, it makes $5000 for 20GB seem like a conservative estimate.
Well, I haven't read the article ... but ... have you ever tried booting an OS from a RAMDisk? I hear people liked doing that with Windows 3.1 - sort of an instant-on feature. While that sort of blazing speed is unnecessary for most storage needs, it would make operating systems less susceptible to hard drive induced interface lag. And stuff. STUFF!!!
They could use FRAM (Ferromagnetic Random Access Memory)
It is as fast as RAM, but is non-volatile. Oh, and its endurance is unlimited. Right now they aren't big enough, but a the technology improves...
lynx -dump http://slashdot.org/ | grep "ead the article"
required UPS, compact flash, etc. Read the article and you may get a
loop" (read the article.) The goofy loop put about seven miles between
Two mentions of "read the article" on the front page. Are they trying to start a fad?
First attempt at being a math nazi....
shouldn't this be "I think I'll keep my magnetic drives and spend my $99,900 on something else."
I used to have a cool sig, back when I cared
"RAM costs more than disk". There. Now you don't need to read the story, which is probably /.ed by now anyway.
High-speed Road Trip (18.000KPH)
I find it amusing that it mentioned using a RAM based swapfile. Doesn't that defeat the purpose of a swapfile???
This guy mentions that compact flash dies after 100,000 to a million rewrites... and that you'll reach that surprisingly quickly if you put your swap file on it.
It seems highly unlikely that any sane person on any desktop system would choose to spend money on compact flash to use as swap, when they could spend less money and buy dram instead - which shuld be faster.
Anyway potentially you only need fast solid state diskspace for your operating system and main applications, since few people need that sort of speed on their 'data files'. I could build a bootable linux box that ran off a 256Mb compact flash - doesn't seem like it'd be too bad at all.
Until SSDs get an order of mangitude cheaper, HDDs will continue to rule! For the thousands that SDDs cost, you can built a huge striped RAID of quick 120 GB drives that will perform more than fast enough for any existing applications. Paintbrush and minesweeper will run like they've never run before.
He obviously knows his stuff but a few more drafts and an editor would have done wonders for this article.
Laws are for people with no friends.
Seriously, I have IDE and SCSI drives that are about 10 years old (capacity is obviously small - in the 200 - 500mb range) and have almost no bad sectors; they still do a reliable job in routers and other boxes that don't require a lot of storage. Meanwhile, newer drives of 2Gb or larger regularly require replacements. Then, there's the problem of recent drive capacities being too large for the BIOSes of my "deprecated" computers, not to mention SCSI connector standards that change more often than the MTV Top 10.
The real problem, for an end-user, though, is the excessively generous storage capacities; as Cringely once pointed out, unless you are a graphic artist, your personal data probably fits well within 500Mb of storage. Why the hell is it that the smallest drives I can purchase nowadays are around 30Gb (120Gb for SCSI), at a time when my data storage needs still have not exceeded that 500Mb per user quota? And, no, my workstations do not suddenly have a use for larger drives either.
One cannot help but notice how manufacturer warranties reflect the lower quality, as well. Where we used to have 5 year warranties (which, in practice, meant that the drive actually performs well for about 10 years), current offerings are guaranteed for 1 year and last exactly that. There's been several recent cases e.g. with IBM's glass drives, where a replacement is required within 6 months from purchase.
I don't know about you, but I have better things to do than constantly wasting money on purchasing replacement drives and time on reinstalling everything on the new drive, only to find out that the BIOS cannot use such large drives, and cursing that I had to purchase a drive whose capacity is exactly 100 times what I can use.
Message to drive manufacturers: Gimme reliable and quiet 2 - 4Gb drives, using the good old 50-pin connectors in both IDE and SCSI flavours, but providing all the modern refinements of Ultra DMA100, etc. and guaranteed for 5 years or more. Make them affordable too. We don't want any more stinky throw-away media storage, thanks you.
Software is not supposed to be about how to work around a useability issue. - Ken Barber
The price per meg on current harddrives is RIDICULOUSLY low, we're all spoiled.
It's basically a dollar a GIG, or less... a 200 gig HD costs 200 bucks.
I'd be willing to pay $200 for a TWENTY gig solid state drive. Ten times the cost, but worth it... too bad no such thing is available.
~Berj
The current basic and EXTREMELY old computer architecture (which is CPU, memory, storage device, and IO devices) already solves this !
You store everything you need on the STORAGE DEVICE, and access stuff by copying it to MEMORY. If you what you need to access is big (like a database) - add more memory.
Actually, the only difference between MEMORY and STORAGE DEVICE is speed. If they were the same speed, we wouldn't have needed one of them. Shoving the memory away from the processor is like saying 'let's put a hard drive instead of memory - that way we'll have hundreds of GBs of memory !'.
To be fair, I'll add that it might help on 2 occasions:
1. Systems which are memory-limited - like my PC which is limited to 4GB. But I'm guessing that computer manufacturers will continue to expand this as needed (both for PCs and servers).
2. Loading-up such a system - reading those GBs from an HDD to the memory will take longer than loading it from memory.
But other than that, I think that stuffing the memory in the storage device and saying that you have a fast storage device might be true, but it's plain stupid !
What if someone started making SSDs for the consumer market, though? How cheap could they be?
Produced at modest volumes in the USA (not made by the boat-load in China), we've been looking at somewhere in the $250 to $300 (usd) range for the bare board with 16 or 20 DIMM sockets, IDE interface, and power management circuitry with aux power inputs.
The unit is planned to fit into the form factor of a cdrom drive, which allows just enough room for 20 sockets and a couple inches to pack in all the circuitry, IDE and power connectors. There just isn't room for a battery, so the plan is to have 2 or 3 "aux power" connectors that accept 9 to 12 volts. We'd make a battery pack that fits into a 5 or 3 inch drive bay and recharges itself from PC power, so you could connect 1, 2, or maybe even 3 battery packs, or maybe a battery pack and 12 volts from some external source like a "wall-wart" power adaptor plugged into a cheap UPS, or maybe something a bit more "reliable". I'm not sure what the battery pack will cost, but it's hard to imagine it'll be over $50-60 even if we splurge a bit for a fancy microcontroller-based rapid charger and advanced battery monitor.
Today, 512 meg DIMMs are the most affordable, and today's pricewatch says about $40 for PC100-SDRAM and $46 for PC2100-DDR. Prices fluctuate quite a bit... a few months ago the 512 meg PC100-SDRAM was $30. But assuming you pay $40 each for 20, plus $280 for the bare drive and $60 for a battery pack, that puts you at $1140 for a 10 gig ultra-ultra-fast drive. Ouch. Even if the prices drop back to $30, which puts you under four digits, it's still quite expensive.
But not as expensive as the article claims.
Anyway, at this point the project is pure vapor. The earliest you might see it would be about one year from now, but 18 months is more likely. Even though DDR is more expensive today, the design will almost certainly use DDR because it is expected to become cheaper and remain more easily available for the years to come. It's also quite likely I'll do serial ATA only, as S-ATA is going to become the mainstream down the road, and it's already gaining acceptance now. My hope is that 1 and 2 gig DIMMs will become more common and their price/byte will come in line with the 128/256/512M sizes.... 'cause there's no way we're going to get more than 20 DIMM sockets into the 5.25 inch drive bay form factor.
The project also has a number of technical challenges... including the difficulty of connecting that many unbuffered DIMMs (the design will need 4 or 5 separate memory channels and a lot of buffers & PLLs that there aren't really room for on the board).
Well, enough vapor for one day.
PJRC: Electronic Projects, 8051 Microcontroller Tools
That said, I'm looking at a DVD-R drive. While the rewritable DVD's don't work everywhere, the non-rewritables work almost anywhere, and DVD-R discs can be as cheap as $0.70 each (DVD+R's are several times more expensive). This falls well below the $1/Gig for HDD storage, and they are very conveniently removable.
Hardware, software, and blinking lights!
Option three : buy a spare computer with a TON of hard drive space to dedicate as 'offline' storage. It isn't particularly expensive anymore (although no where near as cheap as tape) but it doesn't take a week to do a system backup either. Doesn't have to be a fast state of the art computer, just have a lot of drive space.
: ...
Do a system image once a month of your entire OS, apps, etc... stored to that machine, then just back up your data once a week. If it takes you a week to back up a system now you are only backing it up once a week anyways.
If you were creative you could probably come up with a 1TB server (IDE drives) and a GigE network card for under $1,500.
Notes on your post
Under option 1), if you do RAID5 you always lose the capacity of one disk. If you want to minimize costs use bigger drive sets (ie. in a 6 drive set you lose 17% (one drive), but in two 3 drive sets you lose 33% (two drives.) Granted it is a little difficult to do a 6 drive set using IDE, and SCSI drives are still a little pricey when they get big
Under option 2), if you store the offline drives in a quiet, cool, dry, clean place (those mylar bags they came in when you bought them, for example) I don't think you are going to experience hard drives demagnetizing themselves much.
Glonoinha the MebiByte Slayer
Ouch - come on man quit teasing us. This is EXACTLY what we want, although I would suggest supporting ATA-133 on down. The reason people want to add a SSD is to make an existing computer a LOT faster ... if they have to buy a new computer (that has SATA) simply to use your SSD then the price isn't just the price of your hardware, it is the price of your hardware PLUS the price of a new computer. A hundred million PCs are getting sold this year without SATA support and that means there are a hundred million computers (customers) out there you are insuring you can't sell to if you only support SATA.
...
Secondly, rather than planning your first release to be the superduper box in 18 months, how about a 'pretty good' box that supports regular IDE (ATA-100 on down) in 6 months, sell some to generate some cash flow, learn from the feedback of your early adopters, adapt the engineering changes into your superduper box v2 that is still getting released in 18 months.
Maybe the first generation skips SATA, no battery backup, uses PC100 SDRAM, make it full height (two 5.25" bays) instead of half height if you need the room, perhaps see if a SCSI interface might get you out the door sooner (much less intelligence on the drive in a SCSI implementation)
Lets face it, the first generation of anything usually has pain - so plan on your uber release being v2 in 18 months and release (sell) your first generation in 6 months.
Glonoinha the MebiByte Slayer
Does anybody know how big disk tracks are these days? If 2MB was enough on a 20GB disk, does a 200GB disk need 20GB, because the tracks are 10 times as large, or does the disk have 10 times as many tracks of the same size, or somewhere in between? The price of memory hasn't come down as fast as the price of disks, but it has come down a lot, and 10MB of RAM costs about $1 - even though the price of disks is really competitive, drives might as well have as much as makes sense for current geometries and speeds. The sizes are still likely to be on the order of 10MB, not 256MB, and since there's got to be _some_ chip there, it's cheaper as well as more reliable to just make the chip big enough rather than adding sockets for plug-ins.
Large quantities of write-cache on a disk drive are bad, though, because they're not backed up by battery - the system needs to know that when it's written something to disk, it's really written in some form that can be read back later. Read cache is harmless, because losing it just loses a bit of repeatable fetch work - you need enough to cache a couple of tracks of data, but more than that doesn't usually accomplish much, unless there's a big mismatch between your disk speeds and the bus that transmits to your system memory.
Caching cards are usually silly, unless they either provide battery backed-up RAM or are part of RAID controllers where they can help in the assembly/disassembly process. Their main purpose is to make up for limitations in operating system caching design (i.e. they help Windows a lot more than Unix) or making up for other hardware limitations (e.g. CPU RAM limitations, or bus speed differences, or letting you run server disks off the otherwise-unused AGP port instead of the PCI bus.) Their other main purpose is to take advantage of memory speed / price differences - disk caching works just fine with cheap PCI-100 memory, while system RAM needs to be the fastest Quadruple-Data-Rate Gigahertz-RAMBUS Quadruple-Price memory you can buy to keep the CPU running at maximum speed, so if you're buying large quantities of the stuff, it's sometimes worth spending an extra $50-100 for a card that can hold lots of cheap memory.
Battery-backed RAM cards are actively useful for applications that need secure writes, such as database commits or NFS writes. A decade or so ago, the Legato Prestoserve NFS accelerator cards had a meg of battery-backed RAM, which was enough to commit writes to while waiting for the disk drive to spin. This meant that you could respond to NFS requests in sub-millisecond time rather than waiting 10ms or more for a disk to seek and spin (seek time was still slower than rotational latency back then, plus your request might be queued with other disk requests), so you could handle one or two orders of magnitude more requests per second, and a megabyte was more than enough to buffer traffic from a 10mbps ethernet. Database transactions might be generated much faster than NFS requests, but it was still enough to handle caching for a lot of disk space.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
The special cases are things like /tmp, which look like disk drives but mostly contain files that are created, used, and destroyed, and never really need to be saved on disk if there's enough cache space to keep them. The tmpfs file system type was designed to optimise these - it stores files in RAM and uses the virtual memory mechanisms to handle its data rather than a separate disk partition, and can really speed up applications like compiles because there's no need to wait for disk latencies or to even bother the disk bus with writes in most cases.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks