[Gllug] Loopback mountable image file compression.

[Richard Jones]

On Mon, Aug 24, 2009 at 11:30:20PM +0100, Phillip Lougher wrote:
> Richard Jones wrote:
> >On Sun, Aug 23, 2009 at 07:43:09PM +0000, Phillip Lougher wrote:
> >
> > Actually Squashfs isn't completely irrelevant to this discussion.  You can
> > put a filesystem image inside a SquashFS filesystem, it will be compressed
> > by SquashFS, and the filesystem can be loopback mounted.
> >
> > In fact that's what the Fedora liveCD does, it has a SquashFS filesystem
> > that contains exactly one file, an ext3 filesystem image.
> >
> >There's no benefit to putting a filesystem in a squashfs image for the
> >original poster.
> >
> >The reason the Fedora liveCD does it is because cloop is not upstream,
> >and they can't use a squashfs instead of ext3 because squashfs doesn't
> >support extended attributes (read: SELinux).
> >
> >As I say, squashfs is irrelevant to this discussion.
> 
> That's your opinion, where's your evidence.  Without this, this is FUD.

So you really are seriously suggesting using a squashfs filesystem
containing a single file (the ext3 or NTFS image):

  /fs.img

because squashfs can compress.  Just because squashfs can do this
doesn't make it the right way to do it -- block devices should be
compressed at the block device level, not wrapped in an unnecessary
filesystem layer.

We just switched _from_ using squashfs _to_ using ISO9660 for the
libguestfs test harness[1].  I'll outline the reasons why below.

I hope that these reasons can be resolved in the future or are being
resolved now, because I'd really like to use squashfs.

(1) Squashfs format changed incompatibly between version 3 & 4.

This is a warning to the original poster: if you use squashfs, make
sure you keep the tools you use to create and unpack squashfs around
(as source and binaries) so that you can be sure you will be able to
read images in future.

This issue should be resolved now that squashfs is in the upstream
kernel, but RHEL & Debian stable mksquashfs is still version 3 and
those images are not compatible with recent kernels.

(2) Lack of support for filesystem UUIDs or labels.

Mounting filesystems by named device isn't scalable.  In future we'd
like to only mount filesystems by UUID.

This is a major missing feature that we'd really like to see.

(3) Lack of support for extended attributes, hence SELinux.

I see the documentation says:

  [Todo] Implement Xattr and ACL support.  The Squashfs 4.0 filesystem
  layout has hooks for these but the code has not been written.  Once
  the code has been written the existing layout should not require
  modification.

which is good - I know Fedora would like to use Squashfs directly for
the live CD filesystem instead of the packing ext3-in-a-squashfs
scheme (see above).

Rich.

[1] For the test harness.  libguestfs itself supports squashfs4 and
ISO9660 (and cramfs should anyone seriously want to use that).

-- 
Richard Jones
Red Hat
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug