# mount a gzip image

## calvinrsmith

i have a filesystem in a file that works find when mounted loopback

now i'd like to gzip the image and mount it readonly without having to ungzip it first.

how do I do this?

----------

## Perennial

If you want a compressed read-only filesystem in one file, I'd suggest you try squashfs instead.

----------

## yottabit

Pros/cons of squashfs v. gzip v. bzip2?

----------

## calvinrsmith

Perennial,

Let me explain what i'm doing.

I have drives and for a complete backup I just dd the drive.   This makes for easy restore since I can just dd the image back to a new drive  :Smile:   also they tend to gzip down quite nice so I gzip the images.  Now once in a while I need a file from the backup (ie the drive image) and so I have to ungzip the image (now i have two copies of the image) then loopback mount it and finally when I'm done I have to delete the uncompressed image.

Some of the drive images are linux (ext2/3, reiserfs), some are cd's (iso) whereas others are windows (fat/vfat/fat32,ntfs), some are bootable others are not, some are simple partions others are entire drives.  having to tar, cpio or other such stuff tends to screw things up and make for a more difficult restore

It would be nice to be able mount the gziped imaged, grab what i need, unmount it and be done with it

----------

## Gherald

Instead of gzipping, you could make a squashfs filesystem using the dd image file, and mount from there.

----------

## Perennial

 *yottabit wrote:*   

> Pros/cons of squashfs v. gzip v. bzip2?

 

squashfs is a filesystem, it is not a simple compression utility. SO you can't really compare them

If you want to compare squashfs to dd+gzip/bzip, 

I'd say squashfs:

PRO:

- designed as a space-efficient filesystem: it even restricts then number of inodes it needs to the absolute minimum, this is obviously just better compressing all blocks.

-ease of use: 

  generation with 1 command: mksquashfs

  simple to mount: mount -t squashfs

CON: 

- you'd need kernel support

As for dd with gzip, you could argue that it isn't difficult at all either to generate and that it uses standard tools, but there is no easy way to mount it AFAIK.

And when it comes to compression of filesystems, I think squashfs is better performing (smaller) as it doesn't store unused sectors.

----------

## Perennial

 *calvinrsmith wrote:*   

> 
> 
> I have drives and for a complete backup I just dd the drive.   This makes for easy restore since I can just dd the image back to a new drive   also they tend to gzip down quite nice so I gzip the images.  Now once in a while I need a file from the backup (ie the drive image) and so I have to ungzip the image (now i have two copies of the image) then loopback mount it and finally when I'm done I have to delete the uncompressed image.

 

I now see your objection to squashfs. Squashfs is excellent for archiving, but not if you want to use it as a system backup tool of course.

For that purpose there are others. I now use rdiff-backup for backup, but I don't know if this would work fine with windows filesystems.

Back in the time when I still had windows laying around, I used something called 'savepart', but this was pre-XP era, so still FAT  :Smile:  ....You can find savepart here. Beware this is a DOS tool! But it allows access to ntfs as well by now I see, and it only saves the used sectors, a bit like squashfs.

There is now also a linux alternative, namely partimage.

BTW there are cons to using dd for a backup too...you'd need same sized partition to restore to... If you ever need to replace your HD after a crash by a bigger one, this may be an issue.

 *calvinrsmith wrote:*   

> 
> 
> It would be nice to be able mount the gziped imaged, grab what i need, unmount it and be done with it

 

I agree, but I currently don't know of a way to do this easily.

----------

## Joshua5526

Am looking for this solution as well.  It looks like this link gives a possible answer.  Haven't tried it myself.

http://blogs.gnome.org/muelli/2012/10/loopback-monting-huge-gzipped-file/

----------

## NeddySeagoon

calvinrsmith,

Why do you use dd and not tar for backups?

dd makes an image of the entire drive, free pace included.  tar will just save the files on the filesystem. You may compress the tar file 'on the fly' if you wish.

tar allows the recovery of single files, even from compressed tarballs.

The only advantage of dd over tar, is that dd can save the content of the disk space before the first partition too.  If thats important to you, you can dd that separately to a compressed tarball of the filesystem.

----------

## mv

 *NeddySeagoon wrote:*   

> Why do you use dd and not tar for backups?

 

It is probably better to use mksquash than tar+gzip for backups: The time and compression ratio is about the same, but as mentioned it is not a problem with linux kernels to mount it and thus to access or extract single files. And if you have a kernel which cannot access is, you can still unsquash it, so no disadvantage compared to tar+gzip (unless you need to unpack on a windows system - I do not know whether an unsquash exists for windows).

 *Joshua5526 wrote:*   

> It looks like this link gives a possible answer.

 

I think this is a false information: avfs can make a tar+gz "appear" as unpacked, but this cannot work "on the fly" due to the tar+gz format - avfs must unpack at every single access or keep a huge cache. (IIRC avfs uses a clever mixture of both, but access is slow anyway for huge files and needs a lot of local disk space.)

----------

## s4e8

Yes. mksquashfs is the best. It exclude free spaces and do de-duplicate, and has multithread compressor.

----------

## natenjo

Hello

 I successfully managed it with AVFS

cd /root/.avfs/path/to/folder/where/dd/is/located

losetup /dev/loop5 image-mit-gzip.dd.gz#

mkdir /mnt/wo/die/image/eingehangen/werden/soll

mount /dev/loop5 /mnt/where/it/sould/be/mouted

(via http://blog.dreessen.it/?p=112)

Works very well for me!

----------

## augury

I don't know that gzip retains the filesystem formalities required for a clean contigous stream which could be dealt with as a successful mount.

----------

