Why not authenticate full-disk encryption? Common FDE software (TrueCrypt, BitLocker, dm-crypt) doesn't authenticate ciphertext stored on the disk. The commonly cited reason is "it would take too much space", reasoning that you would need an authentication tag for every sector and that would eat significant percentage of available space.

With 512-byte sectors and HMAC-SHA256 for authentication, you would consume roughly 6 % of disk space if each sector was fully authenticated. I could understand that someone would consider this amount to be too much, but if that's the case, you could simply truncate the HMAC tags, for instance to 64 bits (still better than nothing, right?), and use less than 2 % of total space.

With 4096-byte sectors, space is a complete non-issue, less than 1 % is spent on per-sector HMAC tags. Especially for AES-CBC-ESSIV where malleability is a significant risk, this seems like a price well worth paying.

Given that with CBC you need to re-encrypt the whole sector every time anyway, I don't see how authentication would matter even in terms of performance.

So, are there reasons for not using authentication that I'm missing?
Authentication and probabilistic encryption are two desirable features which each take up a small amount of extra space. And you are absolutely right that the percentage of space consumed is of no concern in most scenarios.

But as the other answers also point out that means you can no longer fit a logical sector inside a physical sector of the same size. That is a significant practical problem.

In terms of reading it is not a major issue. For example if every 512 byte logical sector requires 592 bytes to be physically stored on disk, you could simply store every group of 32 contiguous logical sectors in 37 contiguous physical sectors.

In such a layout you have the small percentage of slowdown for sequential reads which is to be expected. And each seek is also slightly more expensive because you would need to read one extra physical sector each time you have done a seek.

The real problem is writing. Most of the time when writing a range of logical sectors the first and last sector will only need to be partially written. That means the encryption layer has to read the original, update it, and write it back. That costs expensive additional seeks. Moreover the encryption layer might not know beforehand which is the last sector to be written, so it might end up doing the read-modify-write cycle for sectors in the middle of the range to be updated.

But it gets worse. If the operation is for some reason interrupted (for example kernel freeze or power failure), the cycle may not have been completed, which can corrupt your data.

If the physical disk guarantees atomic updates, the logical layer would not guarantee atomic updates. Instead the logical layer would potentially leave you with a logical sector which produce read errors on every attempt to read.

If the physical disk does not guarantee atomic updates, it gets even worse. The last physical sector written could contain data related to two or more logical sectors. If it got corrupted because of a power failure during write, the logical layer would not only lose the logical sector being written but also other nearby logical sectors which were not even being written to at the time of the power failure.

Very similar problems exist at the file system layer, where one common solution is a journal. But introducing another journal at the block layer means more slowdown and extra disk space usage.

This overhead could be mitigated by moving the encryption to the file system layer. But storage encryption is difficult enough to get right as it is, integrating it with the file system layer makes it a lot more complicated and thus more error prone.

There is another layer of complexity once you realize that protecting the integrity of individual sectors is not even sufficient. If each sector is individually protected by a MAC (or similar) an adversary could selectively revert individual sectors to an earlier point in time.

By selectively reverting a subset of sectors the adversary can construct contents which does not match any earlier point in time.

To see why this is bad imagine a file was deleted and the sectors it covered were reused for a different file. The adversary could combine the metadata from when one file existed with the data sectors from when the other file existed. This means the adversary has successfully moved the protected data from one file to another. If one of the files was highly confidential and the other was one that you would happily share with anybody, the adversary would be able to trigger a leak of confidential data.

You could protect against this by computing a hash-tree over the disk and storing a MAC of the root of this tree. This makes updates even more complicated, and updating a sector is now going to take logarithmic time rather than the constant time we were used to.

The worst problem however is that you still need to protect the integrity of the crypto code. If the code to do all the cryptography is not protected, an adversary could simply modify that code to bypass all the security measurements. And not only the crypto code itself, but also all the code used to bootstrap the system to the point where it can start reading the encrypted disk needs to be protected.