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.

Sounds like an OS problem ...

[dougmc]

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.

Sounds like an OS issue. Linux handles 200+ GB drives just fine on my p3 box with ATA/33 controllers.

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.

Re:3.0Gb/s - 817 Mb/s?

[teg]

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.

Re:3.0Gb/s - 817 Mb/s?

[jm92956n]

Maybe so you can put two drives on one controller?

Yes.

Re:3.0Gb/s - 817 Mb/s?

[Anonymous Coward]

That's 3Gb/s from/to cache, 817Mb/s to/from spinning elements. Also, latency figures in...

Re:3.0Gb/s - 817 Mb/s?

[archen]

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.

Not to taco

[stratjakt]

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.

Thread on SR

[Sivar]

There's an interesting (as far as "new drive is bigger than old ones!" is interesting) thread [storagereview.net] 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.

Re:Why not faster?

[chill]

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.

Re:Sounds like an OS problem ...

[Richard_at_work]

No, there are quite a few motherboard chipsets that only show at max the first 130GB of the disk, ignoring the rest. This is the maximum they can address. Some BIOSes are happy to hand addressing off to the OS, some arent, so your point of getting the kernel in the lower boundry is a little bit pointless when you want to dual boot. Dont assume that just because you havent come across it it must not exist, because it does and its a pain.

Re:Why not faster?

[stratjakt]

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.

Not applicable

[Junta]

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).

Re:Why not faster?

[314m678]

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

Re:Why not faster?

[vadim_t]

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.

Yes, its called Serial Attached SCSI -

[Anonymous Coward]

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.

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 [wikipedia.org]

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_ General_overview_public.pdf [scsita.org]

Mod parrent -1, troll

[Anonymous Coward]

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

[Macrat]

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.)

Re:Well what an interesting article

[Wesley Felter]

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.

400GB for $330ea

[Macrat]

You can get the Hitachi 400GB drives from http://www.zipzoomfly.com/ [zipzoomfly.com] ZipZoomFly for $330.

Re:yay!

[ganesh129]

I have to agree with the correct spelling of pr0n

Re:Sounds like an OS problem ...

[dougmc]

This is the maximum they can address. Some BIOSes are happy to hand addressing off to the OS, some arent

Once you get booted up, it's not up to the BIOS anymore, unless you're using an old OS that uses the BIOS for disk access.

By old, I mean DOS old -- I don't even think Windows 95 uses the BIOS for disk access once booted up unless it has no other choice. OS/2 had an int 13h driver that it could use if there was no other option -- but you certainly didn't want to use it unless you had to, because the performance sucked.

The problem is that Windows blindly trusts what the BIOS returns for the drive parameters. A smart OS can ignore the BIOS settings if they don't match what the drive itself returns. It can also look at the partition table and use those settings instead of what the BIOS reports, if that makes more sense.

so your point of getting the kernel in the lower boundry is a little bit pointless when you want to dual boot.

I said OS issue. I meant it.

Dont assume that just because you havent come across it it must not exist, because it does and its a pain.

Oh, I've come across it. And I know it's a pain. But I certainly wouldn't replace a motherboard for it -- I'd either 1) update the BIOS (if an update available), 2) add an external IDE card (which has it's own BIOS), or 3) or pick an OS that can handle the BIOS issue better. Another option might be one of those `boot managers' that comes with the large drives as well -- they add a little bit of code that fools Windows into seeing the correct drive parameters instead of what the BIOS returns.

But if my P120 box can read a 200 GB disk with it's internal controller, I'm guessing that almost anything can. But the BIOS on that computer can't handle anything over 8 GB properly, so Windows would be out of the question.

Re:Well what an interesting article

[Detritus]

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.

Re:Hitachi, feh

[retro128]

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!

Re:Sounds like an OS problem ...

[drinkypoo]

You are talking pure bullshit. "BIOS's that dont hand off addressing to the OS" is a nonsensical phrase that proves beyond the shadow of a doubt that you do not know what you are talking about. There are only operating systems that do direct disk access, and operating systems that do disk access through the BIOS. Actually, there is one other distinction: Operating systems which get information about the drives from the BIOS, and those which do not. While I cannot speak for Windows, the ability to get drive information from the BIOS is an experimental feature in Linux, meaning only developers and people who cannot live without it should be using it and it is certainly not the norm.

Since the BIOS is not even jumped into by some operating systems, it has NOTHING to do with ANYTHING after booting. Period. The BIOS is NOT some magical layer in between the OS and the hardware, it is just some code. If the OS does not explicitly use it, it has NO EFFECT WHATSOEVER on the function of the machine.

Go back to my hole? Go learn the actual function of the PC BIOS, and how it works, perhaps by studying DOS assembly programming. You obviously do not understand it now. When you use the bios through the x86 INT instruction, it stores an address, uses the vector table to figure out wher e to jump, and jumps to that address. It begins executing code from there until it is told to return, at which point you code picks up where it left off. No INT, no BIOS. Build a bridge and get over the fact that you are wrong.

Unnecessary, if you get a motherboard

[Anonymous Coward]

like the MSI K8TNeo2 [msicomputer.com] which has built-in SATA HD support and works fine in Linux 2.6.x with SATA enabled in the kernel config.

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 /dev/hd[a-z] to /dev/sd[a-z] which is mildly important to know when setting up a SATA boot device.

find linux-2.6.10/Documentation -type f -exec grep -iw sata '{}' \;