It so happens that storing both hashes, or reversing the capslock effect and trying both versions, really reduces security by a factor which is between 1 and 2. It is a bit tricky to see, so let's define things clearly.
I am using the caps-reverse notion of capslock. If the capslock effect is really an everything-is-uppercase effect, then you should never accept or store that all-uppercase version; instead, return a warning as @D.W. suggests.
I assume that you use a slow and salted hash function like bcrypt (if you do not then that is a bigger issue and you should fix it first). The "slow" part is configurable with an iteration count that you raise as much as you can, based on two constraints: the CPU budget for the hashing (depending on how much free CPU you have and how many client connections per second), and the user patience (which is never very high). The cost for the attacker is directly proportional to the iteration count. If you store two hash values (for the "normal" and "capslocked" version of the password), then both must have their own salt.
When you "try" the password sent by the user, and then "try again" with a capslocked version of the same password, then you are actually hashing twice, so there is an overhead on your constraints. On average, the CPU effort will be multiplied by 1+f, where f is the proportion of wrong passwords (f = 0 if all the users type perfectly, f is very close to 1 if all the users are chimpanzees who must try a dozen times before typing their password correctly). Also, every time you have to try the capslocked version of the password, then the user has to wait twice longer before being granted access (if the capslocked version turns out to be correct) or being ignominiously rejected (if the password is really wrong, capslock or not). To some extent, average users are a bit more understanding about delays when they feel it is their fault, because they typed wrong, but I would not count on it.
The net effect is that testing for two versions of the password increases the cost by a factor which is between 1 and 2; correspondingly, you must then decrease the iteration count by that factor, and the attacker's effectiveness is multiplied by that factor.
This is really a trade-off between user experience (which means "helpdesk costs" in many cases) and security. If possible, it is probably better to detect that the capslock is pressed and warn the user before the password is entered; however, this may prove difficult (I know a site which succeeds in doing that when the client is Internet Explorer, but fails with Chrome and Firefox; instead, it emits visible warnings for each uppercase letter, which is quite bad because the warnings are visible from afar, so that's a leak of information about the password).