Subject: OT: LUKS encryption -- block by block, file by file, or "one big lump"

[rhkramer@gmail.com]

I am curious about the integrity of LUKS (that is, the ability to preserve 
data in the event of corruption on the disk or such).

Aside: I know that backups are a solution / requirement (and I have some 
(well, one, atm)), and I know that there is the ability to backup (and 
restore) the LUKS headers in particular, but my question is something like 
this:

The question:  Suppose disk corruption corrupts one block in the data storage 
area of a LUKS partition / filesystem (I'm not asking about corruption in the 
headers or some other area of "metadata").  In the case of one block of 
corruption in the data storage area:

   * can files in the LUKS partition other than the one with the one block 
corrupted be read correctly?

   * assuming the file with the corrupted block is bigger than one block, can 
the other parts of the file (not including the corrupted block) be read 
correctly?

Something I don't know is whether LUKS does encryption separately for each 
block (or maybe for each file) or whether somehow the result of encryption is 
one big "lump" of data (all files intermixed in the filesystem) and if 
corruption of any individual block will render the entire filesystem 
unreadable.  (As I write this, I'm tending to believe that it is the former, 
but curious minds want to know (and I think I have a life or two left ;-) .)

I have done some googling on this, but haven't found the magic combination of 
keywords.  Some of the searches I tried:

   * [LUKS partition zero before formatting]
   * [encrypted filesystem power loss]
   * [LUKS one block corrupted]

More background: in searching to understand the reason for zeroing the LUKS 
partition before utilizing it (either before or after the luksFormat step) 
(which I now understand -- in short, it is to fill it with random data!), I 
found a recommendation: "Note that when the encryption is in use, we need to 
turn off write caching for our disk."  

I wanted to try to understand why write caching should be turned off, or if an 
encrypted filesystem is any more vulnerable to loss (corruption) of one block 
than a non-encrypted filesystem.