From mboxrd@z Thu Jan 1 00:00:00 1970 From: Phillip Lougher Subject: Re: [PATCH 0/2] cramfs: Add mount option "swapendian" Date: Thu, 15 Nov 2007 22:48:12 +0000 Message-ID: <473CCCAC.5010304@lougher.demon.co.uk> References: <200711152129.25686.lists-receive@programmierforen.de> <200711152135.16932.lists-receive@programmierforen.de> <200711152215.08695.lists-receive@programmierforen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Andi Drebes , linux-fsdevel@vger.kernel.org, Christoph Hellwig , Andrew Morton To: Linus Torvalds Return-path: Received: from anchor-post-35.mail.demon.net ([194.217.242.85]:1310 "EHLO anchor-post-35.mail.demon.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753275AbXKOWrz (ORCPT ); Thu, 15 Nov 2007 17:47:55 -0500 In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Linus Torvalds wrote: > > > But it should be *trivial* to compress the metadata too if the code just > were to put the metadata at the beginning of the image, and the real data > at the end, and then you can build up the image from both ends and you > *can* have a fixed starting point for the data (up at the top of the > image) even though you are changing the size of the metadata by > compression. > I decided to compress the metadata when I designed Squashfs, a read-only filesystem which was inspired by Cramfs. Squashfs stores the data at the front of the filesystem and puts the metadata at the end, so the data is always at a fixed point. Doing that and a couple of other things allows the metadata to be built up and compressed in one-pass while the filesystem is being created. The metadata is split into an inode table and a directory table and compressed separately because it compresses better than way. > But I literally designed and wrote the thing in a couple of days, and I > really didn't think it through right. As a result, the metadata may be > dense, but it's totally uncompressed. It would have been better to allow a > less dense basic format (allowing bigger uid/gid values, and offsets and > file sizes), but compress it. > Squashfs stores much more metadata information, but as it is compressed it is much smaller than Cramfs. Typically the inode table compresses to less than 40% and the directory table to less than 50%. > So a "v2" cramfs would be a great idea. That is what I always considered Squashfs to be. But I also made the mistake of making Squashfs both little and big endian. That's going to be fixed and then I'll make a second attempt at submitting it for inclusion in the mainline kernel. Phillip