From: "Jörn Engel" <joern@logfs.org>
To: Ricard Wanderlof <ricard.wanderlof@axis.com>
Cc: linux-mtd@lists.infradead.org, "Jörn Engel" <joern@logfs.org>,
"David Woodhouse" <dwmw2@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: Wed, 23 Jan 2008 14:01:55 +0100 [thread overview]
Message-ID: <20080123130144.GD24953@lazybastard.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0801231248400.25733@lnxricardw.se.axis.com>
On Wed, 23 January 2008 12:57:09 +0100, Ricard Wanderlof wrote:
>
> Perhaps it's possible to devise something that at least accomplishes part
> of the goal. Such as when writing a new block, also write some statistical
> information such as the number of read accesses since the previous write
> (or power up), or the reason for writing (new data, gc because of
> bitflips, ...) and a write counter. Something of that nature.
I'm still fairly unconvinced about the read accounting. We could do
something purely stochastic like accounting _every_ read, but just with
a probability of, say, 1:100,000. That would still, within statistical
jitter, behave the same for everyone. But once we depend on the average
mount time of systems, I'm quite unhappy with the solution.
Also, logfs stores a very limited amount of data for each segment (read:
eraseblock). Currently this is just the erase count, used for wear
leveling and the segment number. The latter can be used to detect
blocks being moved around by "something", be it an image flasher,
bootloader, FTL or whatever. There are still 16 bytes of padding in the
structure, so we could add an error counter without breaking the format.
> I'd be a bit wary of this with NAND chips some of which have a 100 000
> maximum erase/write cycle specification, though. And I think that
> especially when nearing the maximum value and going beyond it, that there
> is some bit decay occurring over time and not just from reading.
It doesn't really matter whether the data degrades from a number of
reads or from time passing. With a constantly high write rate, there is
less time for degradations then with a low write rate.
Problematic would be to have a high write rate for a while, then a very
low write rate that allows data to rot for a long time. And also this
depends on your numbers being representative for every flash chip. ;)
Jörn
--
The only real mistake is the one from which we learn nothing.
-- John Powell
next prev parent reply other threads:[~2008-01-23 13:08 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
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 [this message]
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=20080123130144.GD24953@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