Prev: usbtouchscreen: support bigger iNexio touchscreens
Next: locking issue in vhost_net_set_backend
From: Ferenc Wagner on 16 Mar 2010 09:40
Hi,

In embedded systems, SquashFS over MTD would be a considerable win, as
that would permit configuring without CONFIG_BLOCK. Please find
attached a naive patch against 2.6.33 for this. It does not handle bad
MTD blocks, that could be handled by gluebi (once you're willing to take
the UBI overhead), or by a custom solution later.

For now, 2.6.34 gained pluggable decompressors, so this patch does not
apply anymore, though the main idea holds. My questions: is the
community interested in integrating something like this, should this
patch transformed into something acceptable, or am I a total lunatic?
I don't know a thing about filesystem development, but willing to learn
and refactor. Comments welcome.
--
Thanks,
Feri.

From: Peter Korsgaard on 16 Mar 2010 10:40
>>>>> "Ferenc" == Ferenc Wagner <wferi(a)niif.hu> writes:

Ferenc> Hi,

Ferenc> In embedded systems, SquashFS over MTD would be a considerable
Ferenc> win, as that would permit configuring without CONFIG_BLOCK.
Ferenc> Please find attached a naive patch against 2.6.33 for this. It
Ferenc> does not handle bad MTD blocks, that could be handled by gluebi
Ferenc> (once you're willing to take the UBI overhead), or by a custom
Ferenc> solution later.

Ferenc> For now, 2.6.34 gained pluggable decompressors, so this patch
Ferenc> does not apply anymore, though the main idea holds. My
Ferenc> questions: is the community interested in integrating something
Ferenc> like this, should this patch transformed into something
Ferenc> acceptable, or am I a total lunatic? I don't know a thing
Ferenc> about filesystem development, but willing to learn and
Ferenc> refactor. Comments welcome.

Nice, I have been thinking about that as well. What kind of size savings
are you getting with this?

CC'ing linux-embedded as this might be of interest there as well.

--
Bye, Peter Korsgaard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Vitaly Wool on 16 Mar 2010 15:20
On Tue, Mar 16, 2010 at 5:26 PM, Peter Korsgaard <jacmet(a)sunsite.dk> wrote:
>>>>>> "Ferenc" == Ferenc Wagner <wferi(a)niif.hu> writes:
> �Ferenc> For now, 2.6.34 gained pluggable decompressors, so this patch
> �Ferenc> does not apply anymore, though the main idea holds. �My
> �Ferenc> questions: is the community interested in integrating something
> �Ferenc> like this, should this patch transformed into something
> �Ferenc> acceptable, or am I a total lunatic? �I don't know a thing
> �Ferenc> about filesystem development, but willing to learn and
> �Ferenc> refactor. �Comments welcome.
>
> Nice, I have been thinking about that as well. What kind of size savings
> are you getting with this?

Yeah, I'm interested in that as well.

~Vitaly
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Ferenc Wagner on 18 Mar 2010 13:00
Peter Korsgaard <jacmet(a)sunsite.dk> writes:

>>>>>> "Ferenc" == Ferenc Wagner <wferi(a)niif.hu> writes:
>
> Ferenc> In embedded systems, SquashFS over MTD would be a considerable
> Ferenc> win, as that would permit configuring without CONFIG_BLOCK.
> Ferenc> Please find attached a naive patch against 2.6.33 for this. It
> Ferenc> does not handle bad MTD blocks, that could be handled by gluebi
> Ferenc> (once you're willing to take the UBI overhead), or by a custom
> Ferenc> solution later.
>
> Ferenc> For now, 2.6.34 gained pluggable decompressors, so this patch
> Ferenc> does not apply anymore, though the main idea holds. My
> Ferenc> questions: is the community interested in integrating something
> Ferenc> like this, should this patch transformed into something
> Ferenc> acceptable, or am I a total lunatic? I don't know a thing
> Ferenc> about filesystem development, but willing to learn and
> Ferenc> refactor. Comments welcome.
>
> Nice, I have been thinking about that as well. What kind of size savings
> are you getting with this?

I could only compare apples to oranges before porting the patch to the
LZMA variant. So I refrain from that for a couple of days yet. But
meanwhile I started adding a pluggable backend framework to SquashFS,
and would much appreciate some comments about the applicability of this
idea. The patch is (intended to be) a no-op, applies on top of current
git (a3d3203e4bb40f253b1541e310dc0f9305be7c84).
--
Thanks,
Feri.

From: Phillip Lougher on 18 Mar 2010 17:50
On Thu, Mar 18, 2010 at 4:38 PM, Ferenc Wagner <wferi(a)niif.hu> wrote:
>
> I could only compare apples to oranges before porting the patch to the
> LZMA variant. �So I refrain from that for a couple of days yet. �But
> meanwhile I started adding a pluggable backend framework to SquashFS,
> and would much appreciate some comments about the applicability of this
> idea. �The patch is (intended to be) a no-op, applies on top of current
> git (a3d3203e4bb40f253b1541e310dc0f9305be7c84).

This looks promising, making the backend pluggable (like the new
compressor framework) is far better and cleaner than scattering the
code full of #ifdef's. Far better than the previous patch :-)

A couple of specific comments...

+/* A backend is initialized for each SquashFS block read operation,
+ * making further sequential reads possible from the block.
+ */
+static void *bdev_init(struct squashfs_sb_info *msblk, u64 index,
size_t length)
+{
+ struct squashfs_bdev *bdev = msblk->backend_data;
+ struct buffer_head *bh;
+
+ bh = kcalloc((msblk->block_size >> bdev->devblksize_log2) + 1,
+ sizeof(*bh), GFP_KERNEL);

You should alloc against the larger of msblk->block_size and
METADATA_SIZE (8 Kbytes). Block_size could be 4 Kbytes only.

+static int fill_bdev_super(struct super_block *sb, void *data, int silent)
+{
+ struct squashfs_sb_info *msblk;
+ struct squashfs_bdev *bdev;
+ int err = squashfs_fill_super2(sb, data, silent, &squashfs_bdev_ops);
+ if (err)
+ return err;
+
+ bdev = kzalloc(sizeof(*bdev), GFP_KERNEL);
+ if (!bdev)
+ return -ENOMEM;
+
+ bdev->devblksize = sb_min_blocksize(sb, BLOCK_SIZE);
+ bdev->devblksize_log2 = ffz(~bdev->devblksize);
+
+ msblk = sb->s_fs_info;
+ msblk->backend_data = bdev;
+ return 0;
+}

This function looks rather 'back-to-front' to me. I'm assuming that
squashfs_fill_super2() will be the current fill superblock function?
This function wants to read data off the filesystem through the
backend, and yet the backend (bdev, mblk->backend_data) hasn't been
initialised when it's called...

Phillip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 |  Next  |  Last
Pages: 1 2 3 4
Prev: usbtouchscreen: support bigger iNexio touchscreens
Next: locking issue in vhost_net_set_backend