One disk speed problem , and a question on hdparm

Home » CentOS » One disk speed problem , and a question on hdparm
CentOS 11 Comments

I believe I’ve posted before about one of the speed issues we were having, of backups taking many, many hours that should not take that long.

My manager and I finally nailed it down to the h/d itself. Identical boxes, and he tried a backup of one system which took under two hours, while the same regular one rand nearly six.

I’d been googling on and off for weeks, and this morning, ran across something: partition alignment. A thread where someone who’d done some tests and found that was his problem.

So, here’s the answer: we have these Caviar Green 2TB drives (the thread I found had either a 1tb, or 1.5tb), (and no, we are NOT going to buy Caviar Green for servers ever again). The big thing is that they use 4k sectors, not 512 bytes. Following directions, I pulled it into fdisk, and then used a command I’ve not needed before: u. This changes units from cylinders (the default) to sectors. Having done that, p shows that it actually starts in sector 63. Again, following directions, I changed it to start in sector 64. Finished the partition, wrote it, made the filesystem, and tried it out.

177G transferred in 1h 47+m.

So, anyone who’s got new drives that use 4k sectors should probably follow this.

This also probably explains parted’s completely aggravating complaint that the partition’s not aligned, but gives you no idea why, or how to align it – I pulled the drive into parted, and told it to print, and it did not complain the partition wasn’t aligned.

Next trick: hdparm. I want to disable, or at least shove way up, the spindown timeout on these drives, which, depending on the thread you read, is 6 or 8 seconds. hdparm should let me do that… but before I do, I’d like to know what it’s set at. Does anyone know how to find that out? And no, the manpage is wrong, hdparm -B it just complains it’s missing the parm.



11 thoughts on - One disk speed problem , and a question on hdparm

  • almost all newer large capacity drives are using 4k sectors internally
    now. SSD physical block sizes are something like 128k bytes, so the
    problem is even worse.

    I’d suggest getting in the habit of using parted rather than fdisk, as
    fdisk can’t handle GPT formatted disks, and MBR can’t handle anything
    over 2TB

  • John R Pierce wrote:

    Yeah… but parted is user hostile. A co-worker and I, both of whom don’t
    need GUIs, use gparted. However, that doesn’t tell me where it’s aligning

    This info – oh, meant to give the link to the author of the informative
    thread: – does tell
    you what and why. Next time I need to build a 3TB drive (which will be
    soon), I’ll play with parted, and see if it complains if I align it this


  • Les Mikesell wrote:

    You may be right… but I’m not sure. We’ll see if the 3tb drive I’ve just
    formatted takes less time – the others I used gparted with.


  • Yes, it is so bad that it is surprising that there is not a text-mode
    program that performs the functions of gparted – or is there one?
    That is, something that gives you a fill-in-the-form setup with
    reasonable defaults, then runs parted (and maybe mklabel, mkfs, etc.)
    for you. Do we really need to run X for that?

  • Hi

    I have been using gdisk for at least a year on Centos and F15/F16

    Current Centos 6.2 server disk was probably partitioned using F15 gdisk
    followed by a custom install of C6.0

    Centos 6.2 gdisk is now installed on the server (maui, 256GB SSD)

    [root@maui ~]# gdisk /dev/sda
    GPT fdisk (gdisk) version 0.8.1

    Partition table scan:
    MBR: protective
    BSD: not present
    APM: not present
    GPT: present

    Found valid GPT with protective MBR; using GPT.

    Command (? for help): p
    Disk /dev/sda: 468862128 sectors, 223.6 GiB
    Logical sector size: 512 bytes
    Disk identifier (GUID): 238914FA-2437-4AD8-B803-5CA2860D9D93
    Partition table holds up to 128 entries
    First usable sector is 34, last usable sector is 468862094
    Partitions will be aligned on 2048-sector boundaries
    Total free space is 2014 sectors (1007.0 KiB)

    Number Start (sector) End (sector) Size Code Name
    1 2048 4095 1024.0 KiB EF02 BIOS boot partition
    2 4096 2101247 1024.0 MiB EF00 Linux/Windows data
    3 2101248 6295551 2.0 GiB 8200 Linux swap
    4 6295552 69210111 30.0 GiB 0700 Linux/Windows data
    5 69210112 132124671 30.0 GiB 0700 Linux/Windows data
    6 132124672 174067711 20.0 GiB 0700 Linux/Windows data
    7 174067712 468862094 140.6 GiB 0700 Linux/Windows data

    Command (? for help): q
    [root@maui ~]# uname -a
    Linux 2.6.32-220.7.1.el6.x86_64 #1 SMP Wed Mar 7 00:52:02 GMT 2012 x86_64 x86_64 x86_64 GNU/Linux


  • But that doesn’t seem happy with MBR type disks. You don’t need GPT
    unless the disk is bigger then 2 Gigs and 4k-sector drives start at
    750G, at least in the laptop sizes. gdisk -l says this about a
    layout created by the Centos installer:

    Partition table scan:
    MBR: MBR only
    BSD: not present
    APM: not present
    GPT: not present

    Found invalid GPT and valid MBR; converting MBR to GPT format.

    Warning! Secondary partition table overlaps the last partition by
    33 blocks!
    You will need to delete this partition or resize it in another utility.
    Disk /dev/sda: 262144000 sectors, 125.0 GiB
    Logical sector size: 512 bytes
    Disk identifier (GUID): 4E46CCD4-4010-401E-84A8-020B674DA64B
    Partition table holds up to 128 entries
    First usable sector is 34, last usable sector is 262143966
    Partitions will be aligned on 2048-sector boundaries
    Total free space is 2014 sectors (1007.0 KiB)

    Number Start (sector) End (sector) Size Code Name
    1 2048 1026047 500.0 MiB 8300 Linux filesystem
    2 1026048 262143999 124.5 GiB 8E00 Linux LVM

    Is something really wrong with it?

  • I’ve found every one of these utilities to be problematic at various
    time, particularly on systems with a GPT bios. Each one seems to have
    its own strengths and weaknesses. Though I don’t remember exactly how
    it works, my recollection is that there are ways to trick fdisk into
    doing alignment by specifying the -H (number of heads) and the -S
    (number of sectors per track). You’ll have 1 unaligned partition at the
    beginning because of the MBR, but all the rest can be forced into the
    desired alignment.