on 3/26/2012 1:49 PM m.roth@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?