All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ivan Djelic <ivan.djelic@parrot.com>
To: David Wagner <david.wagner@free-electrons.com>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	Linux Embedded <linux-embedded@vger.kernel.org>
Subject: Re: usefullness of a read-only block UBI interface ?
Date: Tue, 24 May 2011 19:12:36 +0200	[thread overview]
Message-ID: <20110524171236.GA10795@parrot.com> (raw)
In-Reply-To: <4DDBC64F.5070409@free-electrons.com>

On Tue, May 24, 2011 at 03:53:03PM +0100, David Wagner wrote:
> 	Hello linux-mtd, -embedded and -fsdevel,
> 
> There are a lot of actively developed block filesystems out there, more
> than flash filesystems. Read-only block FS can run with great perfs on
> flash supports with the mtdblock interface (eg. SquashFS) but since it
> doesn't handle bad blocks, read will fail when you hit one.
> 
> That's why we are considering the pros and cons of having a block
> interface on top of UBI: UBI takes care of bad blocks and filesystems
> above it don't have to worry about them.
> 
> An option could be to implement bad block handling in mtdblock but
> then, there wouldn't be any wear-leveling.

Hello David,

Handling bad blocks is one thing, but it would not be enough. I assume you want
to use a nand device (bad blocks ?). Reading nand pages over and over will
result in bitflips (so-called "read disturbs"). Those bitflips are corrected by
ecc in mtd, but they must also be taken care of at a higher level, by
(atomically) moving faulty data to another block and erasing the original
block (which is enough to clear read disturbs). UBI does that in its block
scrubbing operation.

> In case of read-only filesystems, wear-leveling is not so important but
> when read-only and read-write filesystems coexist, static wear-leveling
> is important. And I understand that UBI implements static
> wear-leveling. So it would make sense to have a block read-only
> filesystem on top of UBI along with a ubifs read-write filesystem.

Yes, especially if your read-only filesystem is very large; you need to spread
wear-levelling across the entire device in order to maximize its lifetime.

Regards,

Ivan

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

WARNING: multiple messages have this Message-ID (diff)
From: Ivan Djelic <ivan.djelic@parrot.com>
To: David Wagner <david.wagner@free-electrons.com>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	Linux Embedded <linux-embedded@vger.kernel.org>
Subject: Re: usefullness of a read-only block UBI interface ?
Date: Tue, 24 May 2011 19:12:36 +0200	[thread overview]
Message-ID: <20110524171236.GA10795@parrot.com> (raw)
In-Reply-To: <4DDBC64F.5070409@free-electrons.com>

On Tue, May 24, 2011 at 03:53:03PM +0100, David Wagner wrote:
> 	Hello linux-mtd, -embedded and -fsdevel,
> 
> There are a lot of actively developed block filesystems out there, more
> than flash filesystems. Read-only block FS can run with great perfs on
> flash supports with the mtdblock interface (eg. SquashFS) but since it
> doesn't handle bad blocks, read will fail when you hit one.
> 
> That's why we are considering the pros and cons of having a block
> interface on top of UBI: UBI takes care of bad blocks and filesystems
> above it don't have to worry about them.
> 
> An option could be to implement bad block handling in mtdblock but
> then, there wouldn't be any wear-leveling.

Hello David,

Handling bad blocks is one thing, but it would not be enough. I assume you want
to use a nand device (bad blocks ?). Reading nand pages over and over will
result in bitflips (so-called "read disturbs"). Those bitflips are corrected by
ecc in mtd, but they must also be taken care of at a higher level, by
(atomically) moving faulty data to another block and erasing the original
block (which is enough to clear read disturbs). UBI does that in its block
scrubbing operation.

> In case of read-only filesystems, wear-leveling is not so important but
> when read-only and read-write filesystems coexist, static wear-leveling
> is important. And I understand that UBI implements static
> wear-leveling. So it would make sense to have a block read-only
> filesystem on top of UBI along with a ubifs read-write filesystem.

Yes, especially if your read-only filesystem is very large; you need to spread
wear-levelling across the entire device in order to maximize its lifetime.

Regards,

Ivan

  reply	other threads:[~2011-05-24 17:12 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-24 14:53 usefullness of a read-only block UBI interface ? David Wagner
2011-05-24 14:53 ` David Wagner
2011-05-24 17:12 ` Ivan Djelic [this message]
2011-05-24 17:12   ` Ivan Djelic

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=20110524171236.GA10795@parrot.com \
    --to=ivan.djelic@parrot.com \
    --cc=david.wagner@free-electrons.com \
    --cc=linux-embedded@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    /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.