Ah, you added the `</sarcasm>` tag while I was responding …. Anyway, it was an excuse to break out Frink (http://futureboy.us/fsp/frink.fsp), which reports that the resolution required, which (I think) is (1 foot)/(50 terabytes/byte), is 6 * 10^(-15) m, i.e., on the order of the diametre of a proton. Honestly, I thought it would be much smaller.
Another problem is that any rod etched in this way will have two decodings. :-)
Gah, anti-procrastination settings prevented me from correcting this, but it's too stupid to let stand. At least this post demonstrates once again the important principle that a smart (computer) calculator is no match for a dumb (human) calculator.
Of course, n bytes can store a number up to 2^(8n), not up to n. Thus, the number we'd be recording has order of magnitude (50 terabytes/bit)×log[2]/log[10] ≈ 1.20e+14, so we'd need to distinguish that many digits after the decimal point.
Conversely, as bayes pointed out (http://news.ycombinator.com/item?id=1585498), if we have a resolution of 10 digits after the decimal point, then we can handle about 10*log[10]/log[2] ≈ 33 bits.
(EDIT: To be clear, it's the same person posting; I just can't stand to wait 154 minutes to correct the error.)
Another problem is that any rod etched in this way will have two decodings. :-)