[SGVLUG] resize encrypted filesystem

[Claude Felizardo]

On 10/10/06, Emerson, Tom <Tom.Emerson at wbconsultant.com> wrote:
> > -----Original Message----- Of Claude Felizardo
> >
> > Anyone know if it is possible to resize an encrypted
> > filesystem in place?
>
> I suspect not, and you've almost found out why...
>
> [...]
> > Everything that I can find says to copy the data to another
> > area, do a destructive resize, recreate the encrypted
> > filesystem and then copy the data back.
>
> I'll agree with this (more in a moment)
>
> > ... I've got the data backed up on an external disk but
>
> If it's backed up, then it sounds like you've already accomplished step
> 1 above (copy to...) -- is this external disk ALSO encrypted?
>
> > I'd prefer to do it all in place w/o having to leave an
> > unprotected copy of the files lying about.
>
> Nothing in the above suggestion says the "copy" has to be unprotected --
> it just says to copy "to another area" -- that "other area" can be
> encrypted as well...
>
> Other than speed, since you already have a copy, why the concern over
> doing this "in place"?  (unless you maybe don't trust the copy?)

The partition was like 84 GB consisting of about 15 GB of actual files
that I wanted.  The backup is on a bare bones disk that's sitting in
the drawer so I'd have to pop the case open and move stuff around
(only one IDE bus so I'd have to move the CD drive out of the way).
It's an old snapshot from home consisting of mostly music and pics of
the kids but there were some financial records such as taxes and stuff
which is why it was all encrypted.

> 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...

[snip]

> Does this make sense now?

Anyway, I wasn't able to find a way to do it in place so I copied my
personal mp3s to another partition, did a destructive resize of the
partition, used diskdrake to recreate the encrypted ext3 filesystem
and then moved the data back.

claude