public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: Ricard Wanderlof <ricard.wanderlof@axis.com>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	Ran Shalit <ranshalit@gmail.com>
Subject: Re: Q: Cramfs Vs. Ubifs
Date: Wed, 6 Jun 2012 21:08:41 +0200	[thread overview]
Message-ID: <20120606210841.615fdd6a@skate> (raw)
In-Reply-To: <Pine.LNX.4.64.1206051122380.4247@lnxricardw.se.axis.com>

Hello,

Le Tue, 5 Jun 2012 11:29:08 +0200 (CEST),
Ricard Wanderlof <ricard.wanderlof@axis.com> a écrit :

> I should make it clear that cramfs can not be run directly on NAND flash 
> as it has no concept of bad blocks. But neither can ubifs, which requires 
> UBI. So both require UBI.
> 
> As a matter of fact, come to think of it, I'm not sure how to run cramfs 
> on UBI as it requires a block device which UBI doesn't supply. But I have 
> tested it in some way, so it's probably just my mind drawing a blank right 
> now. :-)

You can use gluebi+mtdblock on top of a MTD volume to use a read-only
block filesystem on top of MTD. Or, you can use the ubiblk driver,
which isn't mainline for now, but has been posted multiple times last
year by one of my colleagues.

> The only real advantage I can see with cramfs is that it does use up less 
> space in the flash for the same amount of data. On the other hand, flash 
> space is usually not a big concern in NAND flash systems anyway.

cramfs is kind of useless now that we have squashfs that overcomes the
limitations of cramfs (in number of files and filesystem size) and
provides an even higher compression ratio.

So definitely, if you had to use a read-only block filesystem, you
should go with squashfs. But as Ricard pointed, you cannot directly use
either cramfs or squashfs on top of MTD partitions, since those
filesystems do not handle bad blocks.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

  reply	other threads:[~2012-06-06 19:09 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-04 19:17 Q: Cramfs Vs. Ubifs Ran Shalit
2012-06-05  8:33 ` Ricard Wanderlof
     [not found]   ` <CAJ2oMhK0isouNBTzMEXPvRLAjFFcSCzWn_gvszrgt1_6Nvw13A@mail.gmail.com>
2012-06-05  9:29     ` Ricard Wanderlof
2012-06-06 19:08       ` Thomas Petazzoni [this message]
2012-06-12  4:54   ` Ran Shalit
2012-06-13  6:55     ` Ricard Wanderlof
2012-06-13 14:26       ` Ran Shalit
2012-06-13 14:59         ` Ricard Wanderlof
2012-06-13 15:25           ` Ran Shalit
2012-06-13 15:32             ` Ricard Wanderlof
2012-06-13 15:46             ` Nathan Lynch
2012-06-14  5:37               ` Ran Shalit
2012-06-14  6:23                 ` Nathan Lynch
2012-06-14  6:57                   ` Ricard Wanderlof
2012-06-06 19:11 ` Thomas Petazzoni

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=20120606210841.615fdd6a@skate \
    --to=thomas.petazzoni@free-electrons.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=ranshalit@gmail.com \
    --cc=ricard.wanderlof@axis.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox