On Thu, 15 Jul 2010 12:10:08 -0600 Bond Masuda <[email protected]> wrote:
> > > > Call me crazy, but I'm guessing you never let it finish syncing in > > the first place. When syncing, it caps its own throughput at some > > arbitrary amount the code deems sensible. Sounds like it never > > un-capped, suggesting you never let it complete the sync process > > before benching it. Further evidence that both numbers are so > > remarkably the same also suggests that. Depending on the size of > > the dataset, it could take a while to finish. I could swear that I > > recall there being some parameter which allows you to create a > > mirror but skip the sync step. If you do that, then basically > > you're swearing on the storage bible that both volumes were zeroed > > before the mirror creation, and the first thing you did after > > creating the volume was mkfs. Personally I've never tried it, and > > searching the documentation, I can't find it now, so perhaps that > > was just a bad dream I had. > > Hi Andrew, > > Thanks for the response. Indeed, we did let it finish syncing.. we > had to let it run overnight to finish syncing. But, we also noticed > that while it was syncing /dev/sda to /dev/sdc, the sync rate as > observed in /proc/mdstat and iostat was limited to 200MB/sec. Drat, I was hoping I caught an easy one ~:^) The similarity in those two numbers does seem a bit coincidental. Is it possible that something with involved with updating the sync information slows it down? That seems a bit far fetched, nm. a _______________________________________________ Linux-PowerEdge mailing list [email protected] https://lists.us.dell.com/mailman/listinfo/linux-poweredge Please read the FAQ at http://lists.us.dell.com/faq
