I think you are asking for a lot more "magic" than is safe here. If you are a mrer "user", you have no business resizing a LUKS container in the first place. You need to know what you are doing to do so safely. Arno On Thu, Feb 04, 2016 at 19:42:43 CET, Michael Kjörling wrote: > On 4 Feb 2016 18:23 +0100, from arno@xxxxxxxxxxx (Arno Wagner): > > if you place a copy of the header at the end, > > It doesn't need to be at the end of the container either; that's just > a convenient spot, particularly because the size of the device backing > the container is already known and it's far away from the beginning of > the container. The most important aspect would likely be that the two > locations are unlikely to be affected by any single error, which is > trivial to show to be the case on HDDs with far-removed LBA addresses, > and is easy to argue is highly likely on SSDs in the same case. > > > 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). > > I don't know anything about what hooks are available or practical, but > an alternative might be to hook into the "resize" control flow and > move the header through there. That would be a much cleaner approach > from a user point of view. > > As a user, I would want a usable encrypted container; I don't really > care where on the disk the metadata to implement this is stored, and I > certainly wouldn't want the documentation to say "oh, and after you > run this, you MUST run this other command" just to keep the container > in a consistent state. That would feel very amateurish. It would be a > bit like if I store a file on a RAID 1, I then have to resilver the > array to make sure that the file is on all constituent devices. > > > > For completeness and security (preventing an old copy > > of the header from lingering), a "luksNukeHeaderCopy" > > would also be required. > > This should be handled transparently by luksErase and/or resize, for > the same reason cited above; all commands that use or affect the LUKS > header should strive to keep the container in a consistent state, > including ensuring that both copies of the metadata are synchronized. > > If absolutely necessary, a command-line switch could be added to > disable that behavior, with clear warnings about the potential > implications. > > -- > Michael Kjörling • https://michael.kjorling.se • michael@xxxxxxxxxxx > “People who think they know everything really annoy > those of us who know we don’t.” (Bjarne Stroustrup) > _______________________________________________ > 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
