> Hi David,
>
> I did consider CRAMFS and JFFS2 when it was announced on the mtd list.
> Conserving flash over system ram is more relevant. Our reasons are below:
>
> RAMFS v/s CRAMFS
> 1. RAMFS is just more stable in terms of less complexity, less bugs reported
> over the time, etc.
> 2. RAMFS is a fairly robust filesystem and all features required as far as I can
> tell.
I'm not aware of any bugs being found in cramfs recently - unless you
wanted to use it on Alpha (or anything else where PAGE_SIZE != the
hard-coded 4096 in mkcramfs.c).
I wouldn't avoid it for those reasons - although if you're _really_ short
of flash space, the same argument applies as for JFFS2 - a single
compression stream (tar.gz) will be smaller than compressing individual
pages like JFFS2 and cramfs do.
> I might be wrong and hence would welcome any suggestions.
Given your stated constraints - you're very short of flash and don't care
too much about the RAM you use, you've may have made the same choice I
would have done.
Bearing in mind that you have to take into account the overhead of the
initrd which does the untarring - what's the total size of the initrd +
tarball on the flash, and what size would the corresponding cramfs be?
If you could fit your root filesystem into a cramfs on the flash, I'd do
that instead and use ramfs for the parts which need to be writeable.
-- dwmw2
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/