[dm-crypt] The future of disk encryption with LUKS2
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
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
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