HD Partitioning

[wobbe]

When you create a new (first) partition where does it end up on the hard drive?
I want to make sure that my O.S. and swap end up on the outside (fast part) of the hard drive. Are partitions created from the outside to inside on the other way around?

[Goran Koruga · Accepted solution]

Hello.

The faster part of the drive is at the beginning - sector 0, where the first partition starts usually.

So put swap as first partition and you'll be fine, but don't expect superb performance because of this (if it starts swapping).

Regards,
Goran

[skt_skt]

/dev/sda1 * 1 8 64228+ 83 Linux
/dev/sda2 9 72918 585649575 8e Linux LVM

/dev/sda1 is used for /boot.The partition (/dev/sda2) is in LVM control and We use / on lvol1 and swap on lvol2 .

[wobbe]

Thanks Goran, that makes sense.
Ik have a dedicated disk for swap so I just create a "small" first partition for the swap area and use the rest of disk to store data that hardly never accessed. I sure don't expect miracles but every bit helps.

[wobbe]

How about raid sets?
Can I assume this works in a simmilar way.
So if I want a really fast disk(partition) I would only use the first 10% of a raid 10 set.

[Matti_Kurkela]

You seem to expect that the difference between the "fast" and "slow" parts of the disk is significant. This may or may not be true: the algorithms that manage the real disk geometry on modern disks are complicated and jealously-guarded secrets.

Before expending too much effort to building RAID sets, make a simple test:

Create three partitions. The first partition should take the first 10 % of the disk, the second 80 %, and the last should take the last 10%.
(The second partition is not important: it was created only to force the third partition to the very end of the disk.)

For a quick test, run "hdparm -t /dev/" a few times on each partition.

For a more accurate test, use bonnie (available in many Linux distributions, but often as an optional package only).

You could do a similar test for RAID sets too.

If you find that the "fast" part is at least 2x as fast as the "slow" part, there might be some real benefit; but if the difference is more like 1.05x (as I'd expect), the benefit would not be worth any significant effort.

If you really need a fast disk so much that you can afford to build RAID 10 sets and then use only the top 10% of them, you should be using your money to buy more RAM and/or Solid-State Drives instead.

MK

[wobbe]

I don't expect the difference to be too great but you should also take into account that read/write head doesnâ t need to travel a whole lot when it only needs to cover the first 10% of the disk. My theory is that this will benefit access times.
Anyway I got this hardware and I want to make sure that I put it to good use. I just want to establish some good practice guideline for myself.
I see if I can manage those tests, could be interesting. Is there a good live cd that supports bonnie? Must run on HP proliant DL380G5.

[Goran Koruga]

Actually the difference is great for sequential reads - as much as 2x or more.

But reality is that this doesn't mean much when things get fragmented.

As for RAID - it depends on how you RAID stuff: if you create individual partitions and then RAID those, the same criterium applies.

Goran

[wobbe]

I've done the bonnie++ test on DL380G5 with 8 disks in raid 10. The difference in performance is minimal!

[Goran Koruga]

Well sure, the difference is big for a single disk configuration, RAID will of course help, especially RAID level 0.

Goran

[wobbe]

I've run the same test with only one disk and I think there is a significant difference when it comes to sequential read write. But look for yourselves the bonnie++ output data is attached to the topic.

Some info about the test:
It was done on a DL380G5 with only one 146GB 10K SAS drive.
The server has a BBWC module and the cache setting was set to default.
(75% write adn 25% read if Iâ m not mistaken)
P01.html is the first 10% of the disk
P02.html the last 10.%
file system was ext3.

I used the following command:
Bonnie++ -u root â p /mnt/p01 â q >> p01.csv

[David Claypool]

In the old days there were X sectors per track regardless of whether it was on the outer or inner rings of the disk. Today, drive manufacturers optimize around the areal density of the media and cram as many sectors as the media allows into each and every track, basically giving the effect of a constant linear velocity data stream to the head.

The operating system's idea of the geometry of a drive is radically different than its physical layout (query the drive and then compare it to the drive's data sheet). You could think you're writing to a track that's in the inner diameter, and in reality you're writing partial tracks somewhere in the middle, and you actually suffer a performance loss because there's a head position move in there in the middle.

Nothing you can do about it, though--the drive's firmware is in control.