Manipulating data on the unit while relayout is in-progress will definitely make it take longer, because now it has to go back and re-do the fault-tolerance data there.
Even just reads slow it down, since access is prioritized over relayout (though in my experience both get horribly slow during relayout).
BeyondRAID is more complex than traditional “stripe across” RAID, therefore so is the fault-tolerance work required.
I think Docchris is right though - there may be “iffy” sectors on some of your drives that are slowing down the process.
During the data-shuffling of relayout, previously-unused areas of the disks are likely to be accessed, and in this access Drobo may encounter bad/iffy sectors that need to be remapped, either by it or the drive itself (I’m not sure which is the case, probably depends on the nature of the error). This can tremendously slow down the process.
That said, my gen 2 Drobo with 4 x 2TB WD20EADS drives took less than 72 hours to rebuild, at half-fill. Again, it’s not an exact science because BeyondRAID only worries about the actual blocks in use, rather than doing a blanket parity on everything.