On 23/11/2018 20:01, Michael van Elst wrote:
mpumf...@mudcovered.org.uk (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
