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

Tom Bishop bishoptf at gmail.com
Tue Sep 28 10:40:26 EDT 2010

The samsung model is not a 4K sector drive, although I did tear it down and
made the partition changes moving it to start at sector 64 vs 63 and also
tried at 2048....when all was said and done, no change in performance.  One
final step that I did make was to move the drive to a different port along
with changing the cable, I moved to the port that the other drive was on and
working fine....after doing that it appears the problem follows the
drive...I am thinking of swapping out the drive and then going from

On Tue, Sep 28, 2010 at 9:10 AM, Ross Walker <rswwalker at gmail.com> wrote:

> 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
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> http://lists.centos.org/mailman/listinfo/centos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.centos.org/pipermail/centos/attachments/20100928/c3fb2c2d/attachment.html 

More information about the CentOS mailing list