[CentOS] RAID rebuild time and disk utilization....

Ross Walker rswwalker at gmail.com
Tue Sep 28 10:10:59 EDT 2010


On Sep 28, 2010, at 12:40 AM, John R Pierce <pierce at hogranch.com> wrote:

>  On 09/27/10 7:49 PM, Tom Bishop wrote:
>> How do I figure out if it's a 4k sector drive, I've read about that 
>> but never looked into it...is there any way to tell, and when you mean 
>> start my partition, I only have one large partition, since this is 
>> just for my data files....so you mean I should start on 2048 and go up 
>> from there???  Thanks in advance...going to do some more reading...
> 
> a lot of new drives are using 4K byte sectors internally for various 
> technical reasons.  they pretend they have 512 byte sectors externally 
> for compatibility
> 
> by default, the first few blocks of the disk is the MBR, then the first 
> partition starts right after that.   if you dont do anything special 
> about this, odds are, 'right after that' is not on a 4K boundary.  you 
> need to 'trim' the start position of the each partition so its on a 4K 
> boundary.

True, traditionally fdisk has made the first partition start on sector 63 (sectors 0-62 holds MBR and maybe grub secondary loader) as that is what DOS did. Sector 63 is 1 sector before the 16th 4k block, thus every read and write will straddle two blocks, sequential IO will suffer since it will have to seek back one for each step forward (if the block isn't in cache), and each write will incur a read.

This can be avoided by manually creating your partition at a given offset and/or manipulating your LVM metadata size so the first extent starts at the proper offset.

Sector 2048 (1MB) was chosen because not only is it on a 4k boundary, but it is also aligned with most RAID chunk sizes, and thus won't straddle two RAID chunks which incurs another penalty.

Windows 2008 and later default to sector 2048 and if you can control the partition offset it's recommended to do the same.

Having said that I don't believe the OP's problem is completely due to misalignment, but a combo of that and hardware problems.

-Ross



More information about the CentOS mailing list