Hi Milan, Great! This helps a lot! I'm going to design our redundant file systems around this. I'm looking forward for your article on better using JSON area. No more question now, at this moment 8-) We definitely will encounter somethings later when implementing this. Will bother you again then. And I'll let you know how we make it here no matter what. Again, very appreciate all you helps, your time and expertise! Best regard, Hualing -----Original Message----- From: Milan Broz [mailto:gmazyland@xxxxxxxxx] Sent: Tuesday, October 29, 2019 9:08 AM To: Hualing Yu <hualing.yu@xxxxxxx>; dm-crypt@xxxxxxxx Subject: Re: 10 M Luks2 header size? On 28/10/2019 14:50, Hualing Yu wrote: > I am sorry that I cannot resist asking more questions as your answer > indicate more opportunities 8-) If they are very simple to you to > answer, thank you for just drop a few lines; if not, you can simply > ignore. > > 1. You said "...if you have no extra user JSON data stored there". > Can we use that area to store additional user data? How? You can create custom token type and import directly JSON through cryptsetup token import command. There is just mandatory type object, otherwise it can be arbitrary valid JSON. (I plan to write some article about it but I promised this months ago ... :-) > 2. To check if a LUKS is in good condition, can we just use > isLuks command? Does this cmd trigger some internal sanitary > checking? Hm, in theory yes (it calls functions that will do autorecovery), so side effect is that it validates JSON areas. But note that any LUKS load will recover invalid JSON area if there is one area valid (it requires access to cryptsetup locks directory and of course write access rights to the image/device). IOW it should "autorepair". If not possible, commands starts to fail as there is no LUKS2 header. Milan _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt
