public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: "Jörn Engel" <joern@logfs.org>
To: Ricard Wanderlof <ricard.wanderlof@axis.com>
Cc: "David Woodhouse" <dwmw2@infradead.org>,
	"Jörn Engel" <joern@logfs.org>,
	linux-mtd@lists.infradead.org, "Josh Boyer" <jwboyer@gmail.com>,
	"Matthieu CASTET" <matthieu.castet@parrot.com>
Subject: Re: Jffs2 and big file = very slow jffs2_garbage_collect_pass
Date: Tue, 22 Jan 2008 16:05:15 +0100	[thread overview]
Message-ID: <20080122150514.GD18884@lazybastard.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0801221419240.25733@lnxricardw.se.axis.com>

On Tue, 22 January 2008 14:24:56 +0100, Ricard Wanderlof wrote:
> >On Tue, 22 Jan 2008, Jörn Engel wrote:
> >
> >Used to be there and was removed.  mtd->erase() does the same as
> >mtd->block_isbad().
> 
> How do you mean? mtd->erase() will not erase a bad block, that is true.

Exactly.  The only use logfs has for block_isbad() is to skip bad blocks
in the beginning when looking for the superblock.

> However, while it seems that mtd->erase() can mark a block bad if it 
> fails, the fact that a block is eraseble without errors does not imply 
> that it is good. I've seen NAND flash blocks which have way passed their 
> specified number of max write/erase cycles still be successfully erased 
> and subsequently written without errors, but the data retention was lousy 
> (blocks started to show bit flips after a few thousand reads).

I think we are being silly[1].  The question is not whether logfs
handles bad block (it does), but which particular failure case it
doesn't handle well enough.

- Easy: blocks are initially marked bad, erase returns an error.
  Mklogfs erases the complete device once, any bad blocks get stored in
  the bad segment table.  Segments can span multiple eraseblocks, one
  bad block will spoil the complete segment.

- Impossible: data rots without early warning.
  If the device is that bad, you can either have a RAID or replace the
  device.  Nothing the filesystem could or should do about it.

- Moderate: one block continuously spews -EUCLEAN, then becomes
  terminally bad.
  If those are just random bitflips, garbage collection will move the
  data sooner or later.  Logfs does not force GC to happen soon when
  encountering -EUCLEAN, which it should.  Are correctable errors an
  indication of block going bad in the near future?  If yes, I should do
  something about it.

The list probably goes on and on.  And I am sure that I would miss at
least half the interesting cases if I had to create it on my own.  But
if Matthieu or you or anyone else is willing to compose an extensive
list of such failure cases, I will walk through it and try to handle
them one by one.


[1] Silly in the way politicians are talking about freedom and security.
Everyone agrees that both are valuable goals and any policy can be
justified in the name of one or the other.  Ensures heated talkshow
discussions, but otherwise useless.

Jörn

-- 
The story so far:
In the beginning the Universe was created.  This has made a lot
of people very angry and been widely regarded as a bad move.
-- Douglas Adams

  reply	other threads:[~2008-01-22 15:11 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-17 16:12 Jffs2 and big file = very slow jffs2_garbage_collect_pass Matthieu CASTET
2008-01-17 16:26 ` Jörn Engel
2008-01-17 17:43   ` Josh Boyer
2008-01-18  9:39     ` Matthieu CASTET
2008-01-18 12:48       ` Josh Boyer
2008-01-18 16:17         ` Matthieu CASTET
2008-01-18 17:55           ` Josh Boyer
2008-01-18 18:17             ` Jörn Engel
2008-01-21 15:57               ` Matthieu CASTET
2008-01-21 21:25                 ` Jörn Engel
2008-01-21 22:16                   ` Josh Boyer
2008-01-21 22:29                     ` Jörn Engel
2008-01-22  8:57                       ` Matthieu CASTET
2008-01-22 12:03                         ` Jörn Engel
2008-01-22 13:24                           ` Ricard Wanderlof
2008-01-22 15:05                             ` Jörn Engel [this message]
2008-01-23  9:23                               ` Ricard Wanderlof
2008-01-23 10:19                                 ` Jörn Engel
2008-01-23 10:41                                   ` Ricard Wanderlof
2008-01-23 10:57                                     ` Jörn Engel
2008-01-23 11:57                                       ` Ricard Wanderlof
2008-01-23 13:01                                         ` Jörn Engel
2008-01-23 13:16                                           ` Ricard Wanderlof
2008-01-23 14:06                                             ` Jörn Engel
2008-01-23 14:25                                               ` Ricard Wanderlof
2008-01-21 22:36                   ` Glenn Henshaw
2008-01-18 17:20     ` Glenn Henshaw
2008-01-18 18:39       ` Jamie Lokier
2008-01-18 21:00         ` Jörn Engel
2008-01-19  0:23           ` Jamie Lokier
2008-01-19  2:38             ` Jörn Engel
2008-01-17 23:22   ` David Woodhouse
2008-01-18  9:45   ` Matthieu CASTET
2008-01-18 18:20   ` Jamie Lokier

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=20080122150514.GD18884@lazybastard.org \
    --to=joern@logfs.org \
    --cc=dwmw2@infradead.org \
    --cc=jwboyer@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=matthieu.castet@parrot.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