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.

12 of 607 comments (clear)

  1. Sounds like an OS problem ... by dougmc · · Score: 3, Informative
    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.

    1. Re:Sounds like an OS problem ... by Richard_at_work · · Score: 3, Informative

      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.

    2. Re:Sounds like an OS problem ... by dougmc · · Score: 3, Informative
      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.

  2. Re:3.0Gb/s - 817 Mb/s? by teg · · Score: 4, Informative

    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.

  3. Re:3.0Gb/s - 817 Mb/s? by jm92956n · · Score: 3, Informative

    Maybe so you can put two drives on one controller?

    Yes.

    --
    An effective signature identifies a particular user amongst a base of thousands.
  4. Thread on SR by Sivar · · Score: 3, Informative

    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
  5. Re:Why not faster? by chill · · Score: 4, Informative

    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.
  6. Not applicable by Junta · · Score: 3, Informative

    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.
  7. Re:Why not faster? by 314m678 · · Score: 3, Informative

    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

  8. Re:Why not faster? by vadim_t · · Score: 4, Informative

    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.

  9. only the 75GXP line by Macrat · · Score: 4, Informative

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

  10. Re:Well what an interesting article by Wesley+Felter · · Score: 4, Informative

    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.