I posted this to developers of squash and get no response, so I will try here.
Is it at all possible to mount a created disk image inside a squash archive ?
I failed to do it.
As root user
I create a squash file system of the diskimage called devsda1.img.sqsh
I create two empty directories
/mount1
/mount2
I mount devsda1.img.sqsh # mount devsda1.img.sqsh /mount1
I tried also with “-t squashfs” option but it mounts the same both ways and makes no difference to result below.
then cd’ing to /mount1 I can see the original image before compression namely devsda1.img
However when I try to mount the original image inside the squash mount, I get the following error.
# cd /mount1
# mount -o ro,loop devsda1.img /mount2
mount: /mount2: cannot mount /dev/loop1 read-only.
I obviously tried with -o loop too, no change (rw).
Surely I must be misunderstanding something as the failure to mount the image is the sole benefit of squashfs over archives like gzip and others only, since you dont have to extract before being able to mount the image inside the squash archive.
I managed to solve the mount issue by brute force and pure luck, but I have no clue why this happens.
using the following it now mounts. #mount -o ro,norecovery,loop devsda1.img /mount2
If I leave out norecovery above then it faIls so mounting it ro is not the solution.
It seems as if squashfs changes something in the tables to prevent it from mounting.
Anyone can explain this to me as my backups need to have integrity if I use squashfs and so far it seems to be very “iffy” and this scares me a bit.
Did squashfs somehow muck up the allocation tables ?
I can mount the image before squashfs and therefore do not expect errors in the image.
I will try
xfs_repair -f
for good measure before I compress with squashfs. Maybe there is something that triggers squashfs to mess with the tables. Probably the duplicate removal routines etc…
Is squashfs actually reliable enough for backups ?
I redone the backup and made sure the original drive has no errors by running e2fsck on the drive before backup.
Problem remains the same and after the squashfs has been created the image can still only be mounted with the “norecovery” option which the only option is that corruption was introduced during squashfs compression.
It definitely seems as if squashfs introduce some form of corruption. How benign or serious it is, is difficult to figure out, but I for one wont use squashfs on large system backups. I will have to stick with dd/tar/gz.
Squashfs is great for small images but I would not recommend it for large archives to be compressed.
Hopefully something better will come around in future that can enable you to mount a compressed image as squashfs does, but just a bit more rugged removing these corruptions introduced…