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 -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
