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 11:57:13 +0100 [thread overview]
Message-ID: <20080123105713.GC24953@lazybastard.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0801231132210.25733@lnxricardw.se.axis.com>
On Wed, 23 January 2008 11:41:14 +0100, Ricard Wanderlof wrote:
>
> One problem may be what to do when the system is powered down. If we don't
> store the error counters in the flash (or some other non-volatile place),
> then each time the system is powered up, all the error counters will be
> reset.
Exactly. If the information we need to detect problems is not stored in
the filesystem, it is useless. Maybe it would work for a very
specialized system to keep that information in DRAM or NVRAM, but in
general it will get lost.
As a matter of principle logfs does not do any special things for special
systems. If you have a nice optimization, it has to work for everyone.
If it doesn't, your systems behaves differently from everyone else's
systems. So whatever bugs you have cannot be reproduced by anyone else.
For example, when the system crashes, some data may get written that
isn't accounted for in the journal. On reboot/remount that gets
detected and the wasted space is skipped. Writes continue beyond it.
On hard disks or consumer flash media, it is legal to rewrite the same
location without erase. But logfs still skips that space and is
deliberately inefficient.
> >I do remember your mail describing the test. One of the interesting
> >conclusions is that even awefully worn out block is still good enough to
> >store short-lived information. It appears to be a surprisingly robust
> >strategy to have a high wear-out, as long as you keep the wear
> >constantly high and replace block contents at a high rate.
>
> You're probably right, but I'm not sure I understand what you mean.
High wearout means short time between two writes. Which also means few
reads between two writes.
As long as the write rate (wear rate) remains roughly constant, high
wear doesn't seem to cause any problems. The block's ability to retain
information degrades, but that doesn't matter because it doesn't have to
retain the information for a long time.
Jörn
--
Victory in war is not repetitious.
-- Sun Tzu
next prev parent reply other threads:[~2008-01-23 11:03 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 [this message]
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=20080123105713.GC24953@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