Hi Sven, if you place a copy of the header at the end, you already need some way to know where the end is and to reserve space at it. A resize could then be as simple as an additional "luksUpdateHeaderCopy" afterwards (whith all other header-changing operations doing that implicitely already). For completeness and security (preventing an old copy of the header from lingering), a "luksNukeHeaderCopy" would also be required. On the other hand, resizing a Luks container with a filesystem in there without killing that filesystem is already complicated enough that I usually just recomend a backup and recreation instead of a resize. Regards, Arno On Thu, Feb 04, 2016 at 17:34:26 CET, Sven Eschenberg wrote: > Hi all, > > Yes data duplication (a secondary shadow copy of the header) > together with checksumming for integrity checking is of course > easier and more straight forward. I thought about FEC (not > necessarily Reeed-S.) as an alternative that covers both issues > without introducing an extra location of header data. Then again, if > the (primary) header is overwritten completely, FECs won't help you > that much. > > The problem with an extra header at the end of the device is, that > it makes growing/shrinking a more difficult task. Currently the > mapping always covers the whole size of the backing device. > > Regards > > -Sven > > Am 04.02.2016 um 10:20 schrieb Michael Kjörling: > >On 4 Feb 2016 09:38 +0100, from gmazyland@xxxxxxxxx (Milan Broz): > >>On 02/03/2016 08:46 PM, Sven Eschenberg wrote: > >>>Personally I'd love to see FEC extensions in a v2 on-disk-format. > >> > >>Anyway, if you have some real use cases for FEC (and specifically some > >>real-world examples of data corruption it can fix), please share it, I am > >>very interested to see that. (I know the problem exist and that FEC could > >>be useful but seems nobody is able provide any hard data...) > > > >Plain data duplication seems both easier to implement and likely to > >allow recovery from the same as well as other classes of errors. > >Reed-Solomon and similar FEC is useful when a read is marginal, but > >useless when a read fails completely, which I believe is a far more > >common failure mode in the layers of storage that we are interested > >in. > > > >Storing the LUKS header in two separate locations on disk could > >probably do the trick. For example, right at the start *and* right at > >the end of the LUKS container, which would avoid any issues with > >having to remap a location in the middle of the container. Put a > >counter in the header, ensure that all copies are in sync when the > >header is read or written to, and if they are out of sync, use the one > >with the highest counter value that works and rewrite the other. Add a > >checksum (could be something really simple even, like CRC32, but it > >would be good to make this extensible without needing to change the > >on-disk format) to protect against any corruption that somehow manages > >to slip past the FEC in the storage layer. > > > >In fact, that would be similar to how ZFS and Btrfs already solves > >pretty much the same problem. > > > >I would discourage complex features; in cryptography, simple and easy > >to validate should be the name of the game, and simply storing the > >same data in two distinct locations is _far_ easier to understand than > >code to calculate and use FEC data. > > > _______________________________________________ > dm-crypt mailing list > dm-crypt@xxxxxxxx > http://www.saout.de/mailman/listinfo/dm-crypt -- 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
