From: "Jörn Engel" <joern@logfs.org>
To: Phillip Lougher <phillip@lougher.demon.co.uk>
Cc: Arnd Bergmann <arnd@arndb.de>,
jaredeh@gmail.com, Linux-kernel@vger.kernel.org,
linux-embedded@vger.kernel.org,
linux-mtd <linux-mtd@lists.infradead.org>,
tim.bird@am.sony.com, cotte@de.ibm.com, nickpiggin@yahoo.com.au
Subject: Re: [PATCH 04/10] AXFS: axfs_inode.c
Date: Fri, 22 Aug 2008 19:19:59 +0200 [thread overview]
Message-ID: <20080822171959.GA30977@logfs.org> (raw)
In-Reply-To: <48AEF2A3.7020905@lougher.demon.co.uk>
On Fri, 22 August 2008 18:08:51 +0100, Phillip Lougher wrote:
>
> Squashfs stores significantly more metadata than cramfs. Remember
> cramfs has no support for filesystems > ~ 16Mbytes, no inode timestamps,
> truncates uid/gids, no hard-links, no nlink counts, no hashed
> directories, no unique inode numbers. If Squashfs didn't compress the
> metadata it would be significantly larger than cramfs.
Elsewhere in this maze of threads Arnd claimed to have tested the
benefits of metadata compression - and it making little impact.
My guess is that it would make a large impact if metadata would be a
significant part of the filesystem image. Usually metadata is close
enough to 0% to be mistaken for statistical noise. So compressing it
makes a significant impact on an insignificant amount of data.
Jörn
--
One of my most productive days was throwing away 1000 lines of code.
-- Ken Thompson.
WARNING: multiple messages have this Message-ID (diff)
From: "Jörn Engel" <joern@logfs.org>
To: Phillip Lougher <phillip@lougher.demon.co.uk>
Cc: cotte@de.ibm.com, linux-embedded@vger.kernel.org,
nickpiggin@yahoo.com.au, Linux-kernel@vger.kernel.org,
linux-mtd <linux-mtd@lists.infradead.org>,
tim.bird@am.sony.com, Arnd Bergmann <arnd@arndb.de>
Subject: Re: [PATCH 04/10] AXFS: axfs_inode.c
Date: Fri, 22 Aug 2008 19:19:59 +0200 [thread overview]
Message-ID: <20080822171959.GA30977@logfs.org> (raw)
In-Reply-To: <48AEF2A3.7020905@lougher.demon.co.uk>
On Fri, 22 August 2008 18:08:51 +0100, Phillip Lougher wrote:
>
> Squashfs stores significantly more metadata than cramfs. Remember
> cramfs has no support for filesystems > ~ 16Mbytes, no inode timestamps,
> truncates uid/gids, no hard-links, no nlink counts, no hashed
> directories, no unique inode numbers. If Squashfs didn't compress the
> metadata it would be significantly larger than cramfs.
Elsewhere in this maze of threads Arnd claimed to have tested the
benefits of metadata compression - and it making little impact.
My guess is that it would make a large impact if metadata would be a
significant part of the filesystem image. Usually metadata is close
enough to 0% to be mistaken for statistical noise. So compressing it
makes a significant impact on an insignificant amount of data.
Jörn
--
One of my most productive days was throwing away 1000 lines of code.
-- Ken Thompson.
WARNING: multiple messages have this Message-ID (diff)
From: "Jörn Engel" <joern@logfs.org>
To: Phillip Lougher <phillip@lougher.demon.co.uk>
Cc: Arnd Bergmann <arnd@arndb.de>,
jaredeh@gmail.com, Linux-kernel@vger.kernel.org,
linux-embedded@vger.kernel.org,
linux-mtd <linux-mtd@lists.infradead.org>,
tim.bird@am.sony.com, cotte@de.ibm.com, nickpiggin@yahoo.com.au
Subject: Re: [PATCH 04/10] AXFS: axfs_inode.c
Date: Fri, 22 Aug 2008 19:19:59 +0200 [thread overview]
Message-ID: <20080822171959.GA30977@logfs.org> (raw)
In-Reply-To: <48AEF2A3.7020905@lougher.demon.co.uk>
On Fri, 22 August 2008 18:08:51 +0100, Phillip Lougher wrote:
>
> Squashfs stores significantly more metadata than cramfs. Remember
> cramfs has no support for filesystems > ~ 16Mbytes, no inode timestamps,
> truncates uid/gids, no hard-links, no nlink counts, no hashed
> directories, no unique inode numbers. If Squashfs didn't compress the
> metadata it would be significantly larger than cramfs.
Elsewhere in this maze of threads Arnd claimed to have tested the
benefits of metadata compression - and it making little impact.
My guess is that it would make a large impact if metadata would be a
significant part of the filesystem image. Usually metadata is close
enough to 0% to be mistaken for statistical noise. So compressing it
makes a significant impact on an insignificant amount of data.
Jörn
--
One of my most productive days was throwing away 1000 lines of code.
-- Ken Thompson.
next prev parent reply other threads:[~2008-08-22 17:19 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-21 5:45 [PATCH 04/10] AXFS: axfs_inode.c Jared Hulbert
2008-08-21 5:45 ` Jared Hulbert
2008-08-21 8:35 ` Carsten Otte
2008-08-21 8:35 ` Carsten Otte
2008-08-21 11:35 ` Arnd Bergmann
2008-08-21 11:35 ` Arnd Bergmann
2008-08-21 12:17 ` Arnd Bergmann
2008-08-21 12:17 ` Arnd Bergmann
2008-08-21 12:17 ` Arnd Bergmann
2008-08-21 15:06 ` Jared Hulbert
2008-08-21 15:06 ` Jared Hulbert
2008-08-21 15:12 ` Arnd Bergmann
2008-08-21 15:12 ` Arnd Bergmann
2008-08-21 15:12 ` Arnd Bergmann
2008-08-22 2:22 ` Phillip Lougher
2008-08-22 2:22 ` Phillip Lougher
2008-08-22 3:23 ` Jared Hulbert
2008-08-22 3:23 ` Jared Hulbert
2008-08-22 3:29 ` Phillip Lougher
2008-08-22 3:29 ` Phillip Lougher
2008-08-22 10:00 ` Arnd Bergmann
2008-08-22 10:00 ` Arnd Bergmann
2008-08-22 17:08 ` Phillip Lougher
2008-08-22 17:08 ` Phillip Lougher
2008-08-22 17:19 ` Jörn Engel [this message]
2008-08-22 17:19 ` Jörn Engel
2008-08-22 17:19 ` Jörn Engel
2008-08-22 18:04 ` Jared Hulbert
2008-08-22 18:04 ` Jared Hulbert
2008-08-22 0:21 ` Phillip Lougher
2008-08-22 0:21 ` Phillip Lougher
2008-08-22 0:21 ` Phillip Lougher
2008-08-22 3:27 ` Jared Hulbert
2008-08-22 3:27 ` Jared Hulbert
2008-08-22 3:46 ` Phillip Lougher
2008-08-22 3:46 ` Phillip Lougher
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080822171959.GA30977@logfs.org \
--to=joern@logfs.org \
--cc=Linux-kernel@vger.kernel.org \
--cc=arnd@arndb.de \
--cc=cotte@de.ibm.com \
--cc=jaredeh@gmail.com \
--cc=linux-embedded@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=nickpiggin@yahoo.com.au \
--cc=phillip@lougher.demon.co.uk \
--cc=tim.bird@am.sony.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.