linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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

      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 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 NNTP newsgroup(s).