[SGVLUG] resize encrypted filesystem

[Mike Fedyk]

Claude Felizardo wrote:
> On 10/10/06, Emerson, Tom <Tom.Emerson at wbconsultant.com> wrote:
>> My take on why resizing "encrypted" partitions will trash data: in
>> modern file systems, "formatting" amounts to writing the underlying
>> "structure" of the file system to disk (directories and inodes,
>> mainly...)  since the "disk" is encrypted, you have to write these
>> "structural marks" in an encrypted fashion, and that is done by virtue
>> of the fact you're going through the encrypted "device driver".
>>
>> When you RESIZE a partition, however, the reads and writes go against
>> the DEVICE itself, not "through the driver", and as such you'll end up
>> reading pointers that are "just plain wrong (encrypted) or worse,
>> attempting to re-writing data in a different location, which will
>> totally hose up the encryption "stream"  (since a good encryption system
>> will encode the same "original" sequence differently each time it
>> appears, merely because it appears "later" in the stream, decrypting
>> things out-of-seuqnece will be really bad.
>
> But then how is resizing on top of LVM different?  Does resize2fs care
> if its on LVM or do you have to use a different tool to resize.  I've
> forgotten.   It was only 2 years ago when i did that presentation on
> RAID and LVM but I must have blocked it all out as a painful memory.
> Something about having to manually rebuild my initrd again...
I haven't worked with encrypted block devices, but maybe I can provide 
some insight.

You have three layers in the encrypted LVM case.  The filesystem is 
within an encrypted image that is contained in an LVM logical volume.  
You can resize the filesystem, but unless you have a tool to resize an 
encrypted image, you're stuck.  If you shrink your LVM logical volume, 
you'll cut off the end of the encrypted image you couldn't resize.

So the key question is: Do you have a tool to resize encrypted images?

Mike