From: David Wagner <david.wagner@free-electrons.com>
To: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Linux Embedded <linux-embedded@vger.kernel.org>
Subject: usefullness of a read-only block UBI interface ?
Date: Tue, 24 May 2011 16:53:03 +0200 [thread overview]
Message-ID: <4DDBC64F.5070409@free-electrons.com> (raw)
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.
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.
So, what do you think about that possibility ? Do you see alternative
approaches or other ways to address the problem of using read-only
oriented filesystems on flash (w/o reinventing the wheel) ?
Regards,
David.
--
David Wagner, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next reply other threads:[~2011-05-24 14:53 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-24 14:53 David Wagner [this message]
2011-05-24 17:12 ` usefullness of a read-only block UBI interface ? 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=4DDBC64F.5070409@free-electrons.com \
--to=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).