Posted by
CmdrTaco
on from the 100-days-of-music-on-/dev/hdb dept.
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?
You can safely use EZ-DRIVE. LILO knows all about it. A couple years ago I bought an 11.5 gig maxstor drive, and the BIOS could only see 8 gigs of it. Since LILO gets the drive info from the BIOS, LILO could also only see 8 gigs of the drive.
My solution was to install the EZ-DRIVE program which allowed LILO to see the entire drive.
RPMs matter a lot for some applications
by
billstewart
·
· Score: 5
What are you trying to _do_ with an 80GB drive? If you're going for maximum playback or recording rate for streaming material, that's one thing; going for fast seek times for an SQL database is another, and file systems are also different.
RPMs matter for video, in that they help a drive crank out data at a high rate, but that also depends on how much data is on a track (and controllers and such). An 80GB drive probably has lot more per track than the once-fuge-and-fast 10GB 7200RPM drives you need for video, so going 5400RPM instead of 7200 probably isn't a big difference, because it's probably still fast enough for real-time.
Most Unix and other file systems tend to be optimized to minimize seek time. This is because back when the theory developed, in the mid 80s, seek times were a lot slower than rotational latency, and you dealt with rotational latency by track caching, especially as memory got cheap enough to cache tracks in the disk drive's controller. Margo Seltzer did some work in the early 90s showing that this was no longer really the case - seek times were down under 10ms, and rotation speeds were mostly 3600rpm, with newer drives using 5400, which meant average rotational delay was 6-8ms. This means that it makes more sense to schedule disk accesses based on expected rotational latency as well as seek time between tracks, because they're now of similar magnitude. That was a few years ago, and seek times have gotten a bit faster, and RPMs have gotten higher, so if you're trying to do cutting-edge random-access file system performance, yeah, you want the high-RPM drive. But if you've got a spare 64MB of RAM for disk cache, you'll optimize most of that away. And if you're using the 80GB for high-performance SQL databases, you can't wait for moving parts anyway, so you've spent the extra thousand dollars for the extra GB of RAM.
--
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Yeah, but when are we gonna effectively use it?
by
carlhirsch
·
· Score: 4
As it stands, we treat our hard drives like really big bags in which to keep all of our stuff.
We don't have the bus speeds or the interfaces to really take advantage of drives this big. You can spin that drive as many RPMs as you want, but do you really think that ATA/100 is going to amount to that much real-world speed? Even the firewire spec, which everybody talks about being such hot shit, doesn't come near to the promised 400MB/s throughputs.
Sure, you can keep a whole heap of DVD movies and MP3's on these huge drives, but it's gonna be some time before technologies start catching up to drives of this capacity.
Also, I'm not an expert on Linux file systems. Can Linux take advantage of huge drives like this for fast searching? Apple's HFS+ does a pretty good job, but the lag starts to show at hefty drive sizes.
-carl
-- .
We've got computers, we're tapping phone lines, you know that ain't allowed - Talking Heads, "Life During Wartime"
I keep hearing people talk about faster processors, faster memory (for the faster processors) and claims that RAM speed is the bottle-neck. Hard drives have made very little speed improvements in the last few years. I bought a WD 340MB drive a few years back that was (I believe) 11 ms. Most of the drives now are what 7, 8, 9ms? I used the drive on a 486DX-40. I now have a Celeron 466. My processor is 10's of times faster, whereas my HD is maybe 50% faster at the most. Yes, it holds a lot more, but it's still slowing my system down.
If SCSI became the standard as opposed to IDE, it may help the situation to an extent, but shouldn't we really be looking at new technologies? What about using flash-drives or something similar. Maybe a 200MB flash-drive to cache the most commonly accessed files (thanks to some new OS enhancement that doesn't currently exist).
Face it. Hard drives are bigger but it would be nice if you could have something smaller that was 10 times faster.
Be careful when buying these large drives. BIOSes often don't support them. I got a motherboard less than a year ago and discovered that it doesn't directly support the 40 gig I just bought. Yes, you can get around it with software like their EZ-BIOS, but that itself has some problems, especially when you are trying to recover. I'm not saying avoid it. Just be aware that it isn't always as foolproof as you'd like. If your motherboard only supports a 40, you might be better off buying to 40s rather than an 80. (Not to mention that you'll get better performance out of two 40s.)
Note to BIOS designers: Would it kill you to design your BIOSes so that they lasted more than a month? I mean, if you're designing a BIOS now, why not allow all sorts of "unreasonable" values, like 4 billion cyclinders, tracks, sectors, etc? Then perhaps we wouldn't have to go through so many gyrations when the terabyte drives arrive.
Slashdot Mirror
You can safely use EZ-DRIVE. LILO knows all about it. A couple years ago I bought an 11.5 gig maxstor drive, and the BIOS could only see 8 gigs of it. Since LILO gets the drive info from the BIOS, LILO could also only see 8 gigs of the drive.
My solution was to install the EZ-DRIVE program which allowed LILO to see the entire drive.
If tits were wings it'd be flying around.
RPMs matter for video, in that they help a drive crank out data at a high rate, but that also depends on how much data is on a track (and controllers and such). An 80GB drive probably has lot more per track than the once-fuge-and-fast 10GB 7200RPM drives you need for video, so going 5400RPM instead of 7200 probably isn't a big difference, because it's probably still fast enough for real-time.
Most Unix and other file systems tend to be optimized to minimize seek time. This is because back when the theory developed, in the mid 80s, seek times were a lot slower than rotational latency, and you dealt with rotational latency by track caching, especially as memory got cheap enough to cache tracks in the disk drive's controller. Margo Seltzer did some work in the early 90s showing that this was no longer really the case - seek times were down under 10ms, and rotation speeds were mostly 3600rpm, with newer drives using 5400, which meant average rotational delay was 6-8ms. This means that it makes more sense to schedule disk accesses based on expected rotational latency as well as seek time between tracks, because they're now of similar magnitude. That was a few years ago, and seek times have gotten a bit faster, and RPMs have gotten higher, so if you're trying to do cutting-edge random-access file system performance, yeah, you want the high-RPM drive. But if you've got a spare 64MB of RAM for disk cache, you'll optimize most of that away. And if you're using the 80GB for high-performance SQL databases, you can't wait for moving parts anyway, so you've spent the extra thousand dollars for the extra GB of RAM.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
As it stands, we treat our hard drives like really big bags in which to keep all of our stuff.
We don't have the bus speeds or the interfaces to really take advantage of drives this big. You can spin that drive as many RPMs as you want, but do you really think that ATA/100 is going to amount to that much real-world speed? Even the firewire spec, which everybody talks about being such hot shit, doesn't come near to the promised 400MB/s throughputs.
Sure, you can keep a whole heap of DVD movies and MP3's on these huge drives, but it's gonna be some time before technologies start catching up to drives of this capacity.
Also, I'm not an expert on Linux file systems. Can Linux take advantage of huge drives like this for fast searching? Apple's HFS+ does a pretty good job, but the lag starts to show at hefty drive sizes.
-carl
. We've got computers, we're tapping phone lines, you know that ain't allowed - Talking Heads, "Life During Wartime"
I keep hearing people talk about faster processors, faster memory (for the faster processors) and claims that RAM speed is the bottle-neck. Hard drives have made very little speed improvements in the last few years. I bought a WD 340MB drive a few years back that was (I believe) 11 ms. Most of the drives now are what 7, 8, 9ms? I used the drive on a 486DX-40. I now have a Celeron 466. My processor is 10's of times faster, whereas my HD is maybe 50% faster at the most. Yes, it holds a lot more, but it's still slowing my system down.
If SCSI became the standard as opposed to IDE, it may help the situation to an extent, but shouldn't we really be looking at new technologies? What about using flash-drives or something similar. Maybe a 200MB flash-drive to cache the most commonly accessed files (thanks to some new OS enhancement that doesn't currently exist).
Face it. Hard drives are bigger but it would be nice if you could have something smaller that was 10 times faster.
Be careful when buying these large drives. BIOSes often don't support them. I got a motherboard less than a year ago and discovered that it doesn't directly support the 40 gig I just bought. Yes, you can get around it with software like their EZ-BIOS, but that itself has some problems, especially when you are trying to recover. I'm not saying avoid it. Just be aware that it isn't always as foolproof as you'd like. If your motherboard only supports a 40, you might be better off buying to 40s rather than an 80. (Not to mention that you'll get better performance out of two 40s.)
Note to BIOS designers: Would it kill you to design your BIOSes so that they lasted more than a month? I mean, if you're designing a BIOS now, why not allow all sorts of "unreasonable" values, like 4 billion cyclinders, tracks, sectors, etc? Then perhaps we wouldn't have to go through so many gyrations when the terabyte drives arrive.
The cake is a pie