[Gllug] Loopback mountable image file compression.

[general_email at technicalbloke.com]

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.
>
> I'm the author of Squashfs, and I think it is relevant.  I'm not
> interested in a stupid, pathetic and public argument, but I don't like
> people spreading FUD about my project.
>
> Cheers
>
> Phillip
>   

Ah well Phillip, that's a stroke of luck :) As you're the author maybe
you could enlighten me... is there a way to get mksquashfs to accept a
stream of data from stdin (the result of a dd) or does it have to
operate on a random access file? I could do with skipping the
intermediate - several hundred gigabyte file on my hard disk - step if
possible.

Failing that might I split the stream into smaller chunks and start
adding those to a squashfs volume before the whole image has been read
or does the whole filesystem have to be in place at the start?

Thanks,

Roger :)
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug