CentOS - Mar 2012 - One disk speed problem [SOLVED], and a question on hdparm

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 <no parm) /dev/sdx does *not* read it,
it just complains it's missing the parm.

         mark

On 03/26/12 1:49 PM, m.roth at 5-cent.us wrote:
> 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.
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                            N 37, W 122
santa cruz ca                         mid-left coast

on 3/26/2012 1:49 PM m.roth at 5-cent.us spake the 
following:
> 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<no parm) /dev/sdx does *not* read
it,
> it just complains it's missing the parm.
>
>           mark
Isn't it sdparm for scsi and scsi emulations?