Slashdot Mirror

rchatterjee writes "SCSI is very close to joining ATA in leaving a parallel interface design behind in favor of serial one. Serial attached SCSI, as the standard will be known, is expected to be ratified sometime in the second quarter of this year according to this article at Computerworld. Hard drive manufacturers Seagate and Maxtor have already said that they will have drives conforming to the new standard shipping by the end of the year. The new standard will shatter the current SCSI throughput limit of 320 megabit/sec with a starting maximum throughput of 3 gigabit/sec. But before this thread turns into a SCSI fanboy vs. ATA fanboy flame war this other article states that Serial Attached SCSI will be compatible with SATA drives so you can have the best of both worlds."

PlatterMan asks: "The question of how to cope with backing up disk drives which are rapidly increasing in size, onto tape and other backup devices which aren't scaling in size as quickly isn't new to Slashdot. Neither is the use of single, raided, and removal disks as backup devices, this has been covered numerous times on Slashdot in e.g. here and here. One thing I haven't really seen discussed however is the feasibility of disk drives as medium to long-term archival media, say 5 to 10 years. Like many people I'm in the position of now having multiple machines with a combined data pool of about 220 Gig, and backing up these onto DDS or DLT tapes is slow and manual to do, and expensive in tape costs. So I'm looking to add a removal drive bay to my primary backup machine and pick up a bunch of large IDE drives, so that I can do regular disk to disk backups over 100 Meg Ethernet (and for my machines which are in cages, over the Net) pulling out and alternating the backup drives on a 3-way backup cycle."

"Backups are of no use without offsite archival copies so I plan to take one set of disks out of the pool, and archive them offsite on a quarterly basis.

However, I've heard horror stories about the data retention and usability off older disks which have been shelved for archival, for example disk stiction - where people try to restore data off of a 4 to 5 year old drive only to find that the disk won't spin up due to solidification of lubricants, or that they've experienced data degradation.

I'd be interested in the Slashdot crowd's opinion on using large IDE drives as an archival media. Clearly one possible problem is being able to get hold of a machine in the future with a suitable IDE interface to plug them into for restoration, but I can't see IDE disappearing within 5 years (maybe 10 though). I'm more interested in experiences and opinions on the suitability of the disks themselves for long-term archival.

• Is stiction still likely occur on newer makes of IDE drives or have manufacturers beaten the problems which caused this in the past?
• Likewise how likely is bit drop-out and general data degradation over say a 5 year and 10 year period, and what do people think would be the likely maximum feasible time that a shelved drive would be usable for?
• Any suggestions as to how would I need to store drives in order to minimize these types of problem and maximise their feasible life as archival media.

Thanks!"

MadCow-ard asks: "With the introduction of the new 160 GB hard drives there comes a problem: they only appear to work with the ATA/ATAPI-6, 48 bit-standard. This means not installing them into systems that I have already built with the de facto 28 bit ATA controllers. I build video editing systems that easily reach 800 Mb, and so the Promise solution with a 2 hard drive ATA controller card doesn't really help. Is there a way squeeze these onto my systems without dropping everything above 137.4 Gb?" 160 gigs on a single HD! How soon before terabyte drives become a reality?

BitMan sent in an overview of the next step in addressing large disk drives. I tend to run into these every few years when I try to add a new, large drive to an older machine and find out that some factor is keeping me from being able to use the full drive capacity. Well, the next step will push those limits out quite a ways, giving us a few more years of ever-increasing drive space.

BitMan writes: "If you haven't heard, there has been a new disk geometry limitation looming for some time at 128GB (gigabytes of 2^30 bytes), which is 137GB (gigabytes of 10^9 bytes). As many will note, there have been various BIOS and OS limitations in disk geometry before -- e.g., 512/528MB, 2GB, 8GB, 32/33GB, etc... But what makes the latest 128/137GB "limit" different is that it revolves around the "hard, physical addressing" limitations of the ATA (AT Attachment) interface. 28-bits are used for addressing, which results in the 2^28 sector * 512 bytes/sector = 128/137GB limitation. As such, hardware fiends like myself were wondering when the industry would get around to addressing this "hard" limitation in the ATA interface.

Fortunately, the solution is already in the works. The ANSI ATA committee has accepted a proposal from Maxtor that extends the ATA bus addressing to 48-bits. This allows for up to 128 pB (petabytes of 2^50), which is 144pB (petabytes of 10^15), sizes. This should tide the PC world over until the 2TB (terabytes of 2^40) limit is reached, which is the maximum number of sectors a 32-bit OS can address -- i.e. 2^32 sector * 512 bytes/sector = 2TB.

In addition to breaking the addressing limitation, another addressing limitation was overcome for performance considerations. The maximum number of sectors transferrable in any command was boosted from 8-bit = 256 sectors/command (~128KB max. transfer/command) to 16-bit = 65,536 sectors/command (~32MB max. transfer/command). This should increase ATA/IDE performance in burst transfers and many other operations.

A whitepaper on the new proposal can be found here from Maxtor. Small correction in the article: Maxtor says 144 pB (petabytes) = 144,000 GB (gigabytes), which is quite incorrect. 144pb (petabytes of 10^15) = 144,000 TB (terabytes of 10^12) = 144,000,000 GB (gigabytes of 10^9).

Thanx goes to the most excellent StorageReview site where I first heard of this."

Ironstorm asks: "Recently I've started to see Firewire harddrives being sold from companies like Maxtor & Western Digital and now I'm pondering firewire storage solutions for high-availability clusters. Does anyone know if it would be possible to share a harddrive between two cluster nodes on a Firewire bus? Or have a node mount another node's Firewire drive if the other node has failed?"

I'm running for prez writes "Network Engines just announced two products that ruin Maxtors previous record of stashing 320 GB in 1U. They are called StorageEngine (4 drives) and StorageArray (8 drives), that both run Ultra160 SCSI (hot swappable). Check out the specs." 640 gigs would be about 192 hours at the top quality tivo record. I could store all my DVDs, all my MP3s, and still have enough room for every episode of South Park and the Simpsons!

Mn3m0nic writes "Maxtor today announced a 320 gig rack mounted network storage server that fits in 1U (1.75") of rack space or 1 terrabyte in 5.25"." 14 bucks a gig. Can you stream video over a 100Mbs ether comfortably? Perhaps this is the backend for your DeCSS based DVD Jukebox? Or the mega Tivo extra hard drive (I s'pose that'd take some work tho). But you could fit a hundred or so movies on there... we're just inching towards it now.

debren writes: "Just as I fork out the cash for a pair of 60GB drives, Maxtor brings out an 80-gigger, which they're claiming is a world record. It's the big story on their main page." Yeah I bought a 40 weeks before they released 60s. Remember when a harddrive was still a big deal?

debren writes: "Just as I fork out the cash for a pair of 60GB drives, Maxtor brings out an 80-gigger, which they're claiming is a world record. It's the big story on their main page." Yeah I bought a 40 weeks before they released 60s. Remember when a harddrive was still a big deal?

EngrBohn writes "The August issue of IEEE Spectrum mentions a proposal by the International Electrotechnical Commission to introduce new prefixes for words that indicate powers-of-two (page 18 of the print issue). This would replace kilobytes (kB) with kibibytes (KiB), megabytes (MB) with mebibytes (MiB), gigabytes (gB) with gibibytes (GiB), and so on. The rationale is two-fold. First is to restore the integrity of the SI prefixes to meaning powers-of-ten. Second is to eliminate ambiguity over whether, for example, a megabyte is 10**6 bytes or 2**20 bytes. Think this is a non-issue? I noticed this morning that Iomega's 100MB Zip disks have a 10**8 byte capacity, and Maxtor also considers a megabyte to be 10**6 bytes. "