Yes, there is still a limit on the size of bitmaps, and the numbers you quote sound about right.
A larger bitmap tends to result in poorer performance as more bitmap updates are required. When a resync or rebuild is required and the bitmap can be used, then a larger bitmap can mean the resync is faster, but there are diminishing returns. Making the bitmap twice as large means half as much IO, but if that reduced the time from 10 seconds to 5 seconds, it might not be worth it.
I would suggest that each bit in the bitmap should correspond to about 1 second's worth of IO. It would be sequential IO, so about 60Meg. With 2TB devices, you only need 2^15bits. Such a bitmap would reduce a 9 hour resync to a few seconds (depending on how busy the drive had been).
Large bitmaps are only really interesting when you are mirroring over a slow link where a second worth of data may only be a Megabyte or less.
If you have a v.fast drive, you would be much better off storing an external journal for the FS on it (Assume you use an FS that supports external journals).
