On 02/22/2017 02:41 PM, Matthias Dahl wrote:

Hello @everyone,

I had an unclean shutdown today and the RAID was (as expected) out of
sync -- so with the next boot, Linux started a resync.

A while into the resync, I had to fire up Windows due to work, and the
Intel Rapid Storage Manager took over the rebuild as expected. But there
was a crucial difference: When I left Linux, I was at somewhat ~35% with
another 2 hours or so to go for the resync, whereas IRSM was at 97% from
the get-go and took just another 10 minutes or so to (apparently) finish
the job.

On Linux, the resync was taking place at 150 MiB/s to 200 MiB/s. So even
if Windows was syncing faster (as-in: transfer-speed wise), there is no way to account for a jump from ~35% to 97%.

That is quite a huge difference and got me worried, since I ran into my fair share of bugs with imsm on Linux, unfortunately.

Is this to be expected and normal behavior? Does IRSM on Win use some kind of optimization/shortcut during rebuild that is not implemented on Linux? Or should this really not be happening and I should indeed be worried that the resync was done improperly now?

This happened with kernel 4.9.5 and mdadm/mdmon 4.0 with a RAID10.

If there you need any more information, please don't hesitate to ask and
I will gladly provide it and help figure this out.

Thanks in advance for any help.

Windows IRSM should not make any "shortcuts" in this case. If you
suspect that resync was not completed properly in Windows, you can run
it manually by writing "repair" to /sys/block/<dev>/md/sync_action. When
it finishes you can check md/mismatch_cnt if there were any
unsynchronized blocks.

Can you share the output of mdadm -E <raid disks> and mdadm --detail-platform?
What version of RST software are you using on Windows?

Thanks,
Artur