Slashdot Mirror
Hitachi to Release Half TB Drive Soon
samdu writes "Hitachi has announced plans to release a 7200 RPM 3.5 inch 500 GB hard drive in the first quarter of this year." Maybe this one won't require a new motherboard to use. I think I've replaced more mobo's to handle larger drives than I have to support faster CPUs.
Seriously, as long as you get the kernel in the part of the disk that your motherboard supports, (or don't boot off that disk at all), Linux will work with it, no matter what motherboard you've got. No 128GB limit to worry about, even if you don't have ATA/100 (or is it ATA/133 that is supposedly required to support 128GB+ drives?)
I've even read those 200+ GB disks on a Pentium 120 Dell's onboard controllers on Linux. No problem -- Linux knew to ignore the BIOS settings on the drive and just made it work.
While it's nice to something as fast as possible, is there a point to have a 3.0Gb/s interface to a product that can only handle 817Mb/s?
On drive cache.
Maybe so you can put two drives on one controller?
Yes.
An effective signature identifies a particular user amongst a base of thousands.
That's 3Gb/s from/to cache, 817Mb/s to/from spinning elements. Also, latency figures in...
Assumably you could have a lot of data pushed down the pipe and have the hard drive cache queue the data until it can be transferred to the drive. Obviously you wouldn't get anywhere near 3Gb sustained transfer though. I'm thinking that 3Gb has more to do with the SATA standard, and nothing to do with the fact that hard drive technology is no where near that level.
I think I've replaced more mobo's to handle larger drives than I have to support faster CPUs.
Why don't you try running linux, which will ignore the BIOS and do it's own HDD geometry homework.
I know you need Windows because linux is hard for non-technical users, but all the drive makers have their own soft-bios utilities to support the larger drives on old hardware.
They have had these since the 2 gigabyte barrier.
There's also add-on controllers if you really need a new interface feature, like the next only-exists-on-paper UDMA speed.
I don't need no instructions to know how to rock!!!!
There's an interesting (as far as "new drive is bigger than old ones!" is interesting) thread on Storagereview.com which includes some insights as to how this thing is built, and why it uses lower-capacity platters than even Seagate's 400GB drives.
Computer Science is no more about computers than astronomy is about telescopes. --E. W. Dijkstra
Seagate Cheetah U320 SCSI drives are available in 15,000 RPM models. Much faster than that and you have problems with the spinning media deforming due to the stress.
Learning HOW to think is more important than learning WHAT to think.
How fast do you think you can make a pound of metal spin with only a few watts of power, without falling apart or exploding, etc?
I don't know exactly what the mechanical problems are, but 10,000 RPM is pretty friggin fast. I remember years ago hearing that 4,800 was the absolute fastest speed they could go for some reason or another.
I don't need no instructions to know how to rock!!!!
While that can apply to SCSI and IDE to a large extent, SATA has dedicated connections to each drive, therefore the sky is the limit as far as multi-drive performance goes (as far as SATA standard is concerned, of course system I/O capabilities and controller capabilities will still limit, but SATA as a standard doesn't impose performance limits in that regard). With SATA assuming a controller can saturate each of it's on board ports, no drive's data transfers would consume data transfer resources from other drives, as is the case with SCSI/IDE (IDE only for two devices of course).
XML is like violence. If it doesn't solve the problem, use more.
Recall from HS physics that the acceleration that a body experiences is proportional to the square of the velocity. So if you make the platter spin twice as fast, you increase the stress on the drive by four. --Paul
Technical issues. It's hard to spin a platter at 10K RPM. It also requires cooling, and makes lots of noise too. 7200 is about the most you can use without having a fan blow on the HDD, and I would prefer not to because they get quite hot. I suppose the manufacturers picture lots of users buying a 10K RPM drive, sticking it into an under-ventilated box and getting a replacement a week later because it died from overheating.
There's also that RPM is not the only way of making things faster. Basically, the performance of a hard disk is determined by 3 variables:
Rotational latency: The time it takes for the disk to spin into the right position. That is, once the head is on the right place, this is how long it has to wait for the data to pass under it. More RPM translates into less rotational latency.
Seeking latency: The time it takes for the drive's assembly to get into the right position.
These two are often added up in the statistics. Solid state drives pretty much lack them. I'm setting up now a firewall that boots from CompactFlash on CF-IDE adapter, and it boots really fast despite a transfer rate of only 2 MB/s. Latency can add up to quite a lot.
Data rate: The speed at which the drive reads or writes data once everything is in the right place. This is a function of the RPM and data density. More speed means the data passes under the heads faster. More density means there's more data per square inch.
So, increasing RPM is one way of getting more performance. The other one is packing more data into the same place. Some drives have small platters for this reason. This also means that a bigger drive is often also faster than a smaller one, given identical RPM, platter size, and number of platters.
On Serial Attached SCSI (SAS) systems. Each controller can address 16,256 devices. SAS is backwards compatible with SATA in that SATA drives can plug into SAS controllers.
_ General_overview_public.pdf
There is actually a _great_ need to increase the communication speed between drives and controller.
For more information on SAS, see my Wikipedia article at:
http://en.wikipedia.org/wiki/Serial_Attached_SCSI
Since wikipedia is down or slow right now, here is the non-wiki version of the article and a link:
Serial Attached SCSI (also known as SAS) is a new generation of SCSI designed to allow for much higher speed data transfers. SAS does this by serial communication instead of the parallel method found in traditional SCSI devices.
SAS supports up to 16,256 addressable devices per port and point to point data transfer speeds up to 3Gbps, but is expected to reach 10Gbps by the year 2010. The SAS connector is much smaller than traditional parallel SCSI connectors allowing for small 2.5 inch drives.
The physical SAS connector is form factor compatible with SATA, allowing for much cheaper SATA drives to connect to a SAS backpane. SAS drives are not compatible on a SATA bus and have their physical connector keyed to prevent any plugging into a SATA backpane.
Serial Attached SCSI supports three transport protocols:
* Serial SCSI Protocol (SSP) - Supporting SAS disk drives
* Serial ATA Tunneling Protocol (STP) - Supporting SATA disks
* Serial Management Protocol (SMP) - Supporting SAS Expanders
SAS General Overview - http://www.scsita.org/aboutscsi/sas/tutorials/SAS
Most modern operating systems (inclding windows) don't trust the BIOS for this, and havent for quite a while.
What the poster is talking about is 48bit LBA which is required to break the 132gig limit.
Indeed a good way to fix this is to use an addon card, just make sure your operating system knows what to do with 48bit LBA. Windows has some issues last time I checked.
Only the 75GXP line was lemons. 120GXP and higher releases have been MUCH higher quality. (Don't argue with me about it as I have FOUR 7K250 drives, a DOZEN 120GXP drives and a DOZEN 180GXP drives in use 24x7 across a variety of desktop systems.)
Of course, operating system limits have nothing to do with motherboard limits. SATA uses 48-bit sector numbers IIRC, so that's a limit of 2^57 bytes. And 32-bit operating systems can use 64-bit filesystems (e.g. XFS) which have no practical size limits.
You can get the Hitachi 400GB drives from http://www.zipzoomfly.com/ ZipZoomFly for $330.
I have to agree with the correct spelling of pr0n
The largest block number supported by the I/O interface is not dependent on whether you are running a 32-bit operating system. There have been various limits for IDE and SCSI controllers, depending on what version of IDE/SCSI was implemented, firmware limits/bugs, BIOS limits/bugs, etc.
Mea navis aericumbens anguillis abundat
All hard disks have magnets in them - Incredibly powerful neodymium ones. They are shielded, of course, but their purpose is to move the disc heads by reacting with the magnetic field of the voice coil located at the back of the head arm. When HD's die I always pop them open and the magnets out. They make GREAT refrigerator magnets and disc erasers!
-R
like the MSI K8TNeo2 which has built-in SATA HD support and works fine in Linux 2.6.x with SATA enabled in the kernel config.
/dev/hd[a-z] to /dev/sd[a-z] which is mildly important to know when setting up a SATA boot device.
Just make sure you ask the linux kernel guys why they still can't be bothered to document the recent (2.6.7) change in the naming of SATA devices from
find linux-2.6.10/Documentation -type f -exec grep -iw sata '{}' \;