On Thu, 19 Jul 2012 10:25:25 -0400 Bill Davidsen <davidsen@xxxxxxx> wrote: > Roman Mamedov wrote: > > On Wed, 18 Jul 2012 22:44:06 -0400 > > Alex <mysqlstudent@xxxxxxxxx> wrote: > > > >> I'm not sure what stats I could provide to troubleshoot this further. > >> At this rate, the 2.7T array will take a full day to resync. Is that > >> to be expected? > > 1) did you try increasing stripe_cache_size? > > > > 2) maybe it's an "Advanced Format" drive, the RAID partition is not properly > > aligned? > > > That's a good argument for not using "whole disk" array members, a partition can > be started at a good offset and may perform better. As for the speed, since it > is reconstructing the array data (hope the other drives are okay), every block > written requires three blocks read and a reconstruct in cpu and memory. You can > use "blockdev" to increase readahead, and set the devices to use the deadline > scheduler, that _may_ improve things somewhat, but you have to read three block > to write one, so it's not going to be fast. > Read-ahead has absolutely no effect in this context. Read-ahead is a function of the page cache. When filling the page cache, read-ahead suggests how much more to be read than has been asked for. resync/recovery does not use the page cache, consequently the readahead setting is irrelevant. IO scheduler choice may make a difference. NeilBrown
Attachment:
signature.asc
Description: PGP signature
