From: Artem Bityutskiy <dedekind1@gmail.com>
To: Bill Pringlemeir <bpringle@sympatico.ca>
Cc: linux-mtd@lists.infradead.org
Subject: Re: RomFS MTD and NAND Flash with ECC (EUCLEAN).
Date: Tue, 20 Sep 2011 10:41:20 +0300 [thread overview]
Message-ID: <1316504487.4849.47.camel@sauron> (raw)
In-Reply-To: <BLU0-SMTP67284C899E8D810036835EB80B0@phx.gbl>
On Mon, 2011-09-19 at 16:19 -0400, Bill Pringlemeir wrote:
> On 19 Sep 2011, dedekind1@gmail.com wrote:
>
> On Fri, 2011-09-16 at 16:46 -0400, Bill Pringlemeir wrote:
> >> #ifdef CONFIG_ROMFS_ON_MTD
> >> -#define ROMFS_MTD_READ(sb, ...) ((sb)->s_mtd->read((sb)->s_mtd, ##__VA_ARGS__))
> >> -
> >> +#define ROMFS_MTD_READ(sb, ...) \
> >> + ({ int res; \
> >> + res = ((sb)->s_mtd->read((sb)->s_mtd, ##__VA_ARGS__)) == -EUCLEAN ? \
> >> + 0 : res; })
>
> > I do not think this is the most elegant way to handle this, but yes,
> > EUCLEAN is used nowadays to report about bit-flips, which are actually
> > not an error, more like an info that this eraseblock needs some
> > attention.
>
> Good. Neither do I. Sometimes code is better at describing a problem.
>
> > I am not sure MTD is the right subsystem for this patch, could you try
> > to send it to fs-devel / Al Viro instead?
>
> I kind of thought it was not a good patch.
|I did not mean this patch is bad, on the opposite - it looks to be of
"similar style" as ROMFS. I just meant that this patch is for a
file-system, so most probably should go in via Al Viro. Feel free to put
me to CC when re-sending.
> I will try to rework it.
> Now, I am sure of 'EUCLEAN's meaning. I also observe that my romfs
> works fine with a NAND flash if the BLOCK device is used.
>
> Currently the romfs code is making a decision based on...
>
> int romfs_dev_read(struct super_block *sb, unsigned long pos,
> ...
> if (sb->s_mtd)
> return romfs_mtd_read(sb, pos, buf, buflen);
>
> The NAND flash will not map directly to a CPU memory space like a NOR
> flash. I *think* the main benefit of this MTD is for the non-MMU in
> directly mapping files? What is the benefit of using the MTD versus the
> block device for NAND flash? [I think that is not a fs-devel
> question...].
For R/O FS there is probably not much benefits, except of less layers ->
a bit faster.
> Also, it is not the place of RomFs to be writing flash. However, if
> there is an EUCLEAN return code, is it worth a printk?
On the one hand, bit-flips happen very often in modern flashes, so if
you print a message on every bit-flip, you may have a lot of messages.
On the other hand, if you use RomFS on a modern flash, you are probably
doing wrong thing because it is unable to handle bit-flips. You should
rather use it on top of UBI. So printing messages is good, because it
would make the user to start thinking about an issue.
So I'd say, overall I think printing a warning is a good idea.
--
Best Regards,
Artem Bityutskiy
prev parent reply other threads:[~2011-09-20 7:38 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-16 20:46 RomFS MTD and NAND Flash with ECC (EUCLEAN) Bill Pringlemeir
2011-09-19 5:05 ` Artem Bityutskiy
2011-09-19 20:19 ` Bill Pringlemeir
2011-09-20 7:41 ` Artem Bityutskiy [this message]
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=1316504487.4849.47.camel@sauron \
--to=dedekind1@gmail.com \
--cc=bpringle@sympatico.ca \
--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.