There's no need to go to great lengths to find a place to store the IV. An encryption mode that bases the IV on block number and propagates changes throughout the disk block provides effectively just as much security. The only theoretical weakness of the latter approach is that if a block's contents are unchanged, the ciphertext will be unchanged. But even with a unique IV per block, in practice this same effect will occur, as if you are not changing a portion of the disk, you're probably not rewriting it, so the old IV will still be in use. Hence an attacker who compares the current disk state against an earlier snapshot will be able to tell which blocks have changed and which have not, in either mode.
Peter Gutmann and Colin Plumb invented a simple trick which provides this property in conjunction with CBC or CFB modes. We're going to encrypt/decrypt a disk block, which is divided into "packets" which are the cipher block size (64 or 128 bits). Let P[j] mean the jth packet of plaintext in the block; assume there are n packets in the block. C[j] is the jth packet of ciphertext. Encryption P[n] ^= Hash(P[1..n-1], blocknum, diskID) Encrypt block using P[n] as IV Decryption Decrypt C[2..n] using C[1] as IV Decrypt C[1] using P[n] as IV P[n] ^= Hash(P[0..n-1], blocknum, diskID) The idea is to use P[n] as IV, first xoring in some function (doesn't have to be a crypto hash) of the first n-1 packets, the block number, and some disk-specific value. Doing this ensures that the IV depends on all the bytes in the block, so a change to any byte will change the entire block. The decryption doesn't have to be split into n-1 and 1 block parts as shown here, any division will do.
