[dm-crypt] The future of disk encryption with LUKS2

Arno Wagner arno at wagner.name
Thu Feb 4 12:01:03 CET 2016

On Thu, Feb 04, 2016 at 11:02:36 CET, Milan Broz wrote:
> FEC is not needed for header resilience, above works pretty 
> well and it is simple.

For smaller things (and on disk the LUKS header qualifies), 
replication and checksumming is always preferrable. 

One problem with FEC on top of HDDs is that you will  
almost always not get bit errors, but full defective 
sectors. The disk already corrects most bit-errors and 
the user only sees errors when the disk has given up. 
That would mean you would need to be able to correct 
4096 missing _bytes_, and that will cause massive FEC 
block sizes, which kills performance. Or alternatively, 
you can distribute all blocks in smaller slices (so 
each REED-SOLOMONS block gets smaller), which also 
kills performance.

For SSDs, the situation would be much, much worse.

This is the reason why FEC is not used in storage
above what the disk itself already does.

In storage, if you really need it, you do RAID1/5/6
and for large installations, RAID5/6 does not have 
much cost overhead. For small ones, adding a second disk
to get a RAID1 is also not going to affetc the overall
cost much.

FEC does have its primary use when you cannot have 
RAID-type redundancy or when you have lots of small 
burst-type errors. That is the case in wireless 
communication or raw HDD reads. It is also the case 
on optical media. It is not the case on disk reads 
on (S)ATA level.


Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno at wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

More information about the dm-crypt mailing list