4
For the purposes of this question, BitLocker refers to the BitLocker-to-go variety on a disk with write-caching disabled.
NTFS supports metadata journaling, which, although not completely failsafe, does mitigate certain types of potential filesystem errors.
Assuming an NTFS volume is protected with BitLocker, does this reduce the failure tolerance? Would a power failure during a write to an NTFS volume, that's protected with BitLocker, be more prone to corruption than on an unencrypted NTFS volume?
Attempt at an example
(Skip this if it doesn't make sense, I can't think of a more concise explanation at the moment.)
This is completely hypothetical, and deals with a different encryption system (not BitLocker), but demonstrates a possible point of failure with encryption, and why saying "BitLocker is invisible to NTFS" is irrelevant. My question is not limited to this example however.
Assume the basic device block size is 8 bytes for simplicity:
| ABCDEFGH |
The third byte of the first block is changed and the entire block is re-written:
| ABzDEFGH |
^
Assuming the write fails after the third byte has been written, we're OK, as none of the following bytes have changed.
However, assume the block is encrypted:
| GTWNSDKQ |
The third byte is changed again, but the encryption cipher results in the entire rest of the block also changing:
| GTx8q1uz |
^^^^^^
If the write fails, we would be left with something like:
| GTx8SDKQ |
^^**** - Not all bytes were updated, entire block is now corrupted
Hopefully that example is simple enough to understand. Obviously the NTFS allocation unit size is much larger than 8 bytes, but it demonstrates a hypothetical problem.
Restating question
To what degree (if at all) does BitLocker suffer from the scenario above or others; anything that would introduce a new point of failure? Would a power failure during a write to an NTFS volume, that's protected with BitLocker, be more prone to corruption than on an unencrypted NTFS volume?
just some more additional thought: http://queue.acm.org/detail.cfm?id=2367378
– akira – 2012-09-25T10:44:15.933