Re: Poor raidframe reconstruct performance on 8-stable

[Jaromir Dolecek <jaromir.dolecek%gmail.com@localhost>]

Can you perhaps try interrupt count via intrctl? iirc someone complained about some interrupt storm coming from acpi. 

> Le 23 nov. 2018 à 21:15, Mike Pumford <mpumford%mudcovered.org.uk@localhost> a écrit :
> 
> 
> 
>> On 23/11/2018 20:01, Michael van Elst wrote:
>> mpumford%mudcovered.org.uk@localhost (Mike Pumford) writes:
>>>> I'm seeing a write speed of 7MB/s which means my 2TB reconstruct is
>>>> going to take 72+hours! Last time I did it it took about 3 hours if I'm
>>>> remembering correctly.
>>> Just updated this to a build from the 17th and there is no change. :(
>> That's a normal behaviour, both disks are compared and if there is
>> a difference, the data from the first disk is copied to the second.
>> That read/write pattern is slow on modern disks.
> Why is this a read/compare? I'm doing a raid1 reconstruct which should be a straight read from disk A, write to disk B. The data from systat backs that up. Each disk is doing ~110 transfers per second. wd1 the source disk is reading at 7MB/s and wd2 the destination is writing at 7MB/s.
> 
> I've reconstructed on this system before with the same disks (the failure is a cabling issue not the disk failing). So unless raid1 raidframe reconstruction has changed in the last year I want to know why an operation that USED to run at 30-40MB/s is now running at 7MB/s. I can't do a direct copy as I need the system to stay up while its reconstructing and the raid FS is a critical volume. Are you really telling me I'd be better off vaping the disklabel and re-adding the old disk as a fresh component to the raid. I thought that's what I had told raidctl to do.
> 
>> You can try to fail the disk again and restart reconstruction.
> That's how I triggered the reconstruct. The disk was already failed so I did raidctl -R /dev/wd2e raid1 to start the reconstruction. In this case I can't understand why it would be doing a comparison at all as it should be assuming that the destination disk is fresh.
> 
> Mike