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. Regards, Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx 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 _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
