Re: loop.c transfer module api

kernel@draper.net
Sun, 5 Sep 1999 04:35:11 -0500


On Sat, Sep 04, 1999 at 07:50:02PM +0200, Matthew Wilcox wrote:
> On Sat, Sep 04, 1999 at 12:21:00PM -0500, kernel@draper.net wrote:
> > On Sat, Sep 04, 1999 at 11:54:11AM +0200, Matthew Wilcox wrote:
> > > On Sat, Sep 04, 1999 at 04:26:35AM -0500, kernel@draper.net wrote:
> > > >
> > > > The #1 issue (I hope!) was that loopback crypto filesystems cannot be
> > > > relocated.
> > >
> > > And, more importantly, cannot be restored off backup. This is really a
> > > very bad problem.
> > >
> > Certainly it can be restored from a backup... by a procedure that
> > preserves the original location of the underlying partition (or file).
>
> Do you have such a procedure?
>

Of course. This question is way off topic for a kernel list. But since
you asked, and since the perception among so many is that encrypted loop
filesystems using absolute block number seeded IVs cannot be backed up and
restored, I will address it here.

The most obvious choice is dd. Example:

dd if=/dev/hda6 of=/dev/something

Where /dev/hda6 is the block device containing ciphertext and /dev/something
is the device to receive the backup. If you choose to backup into files,
beware of 2gig ext2fs file size limitations.

The restore is the inverse:

dd if=/dev/something of=/dev/hda6.

The caveat is that /dev/hda6 must not be repositioned.

dd is not the only option. Any tool which performs a raw image
dump/restore will do. Commercial tools such as Norton Ghost, etc,
come to mind.

As you may infer, it is far better IMHO to associate loop devices with
block devices rather than files. Block devices tend to stay in the
same place on a disk, they don't suffer from 2 gig file size limitations,
they never contain holes, and so forth.

Reed,

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/