From: Peter Menzebach <pm@mw-itcon.de>
To: dedekind@infradead.org
Cc: linux-mtd@lists.infradead.org
Subject: Re: data loss on jffs2 filesystem on dataflash
Date: Thu, 22 Sep 2005 15:31:59 +0200 [thread overview]
Message-ID: <4332B24F.2050305@mw-itcon.de> (raw)
In-Reply-To: <1127393059.20014.105.camel@sauron.oktetlabs.ru>
Artem B. Bityutskiy wrote:
> On Thu, 2005-09-22 at 14:30 +0200, Peter Menzebach wrote:
>
>>OK guys,
>>here we are with a patch for it. I made several tests now with
>>wbuf->pagesize of 1056 and 8*1056 and erase size of 8*1056 and it looks
>>good so far.
>>
>>Open is now the question, if we should implement a possibility to adjust
>>the wbuf_pagesize independently from the jffs2 sectorsize. For my
>>purposes I can live with a wbuf_size = jffs2 sector_size = 8*1056, but
>>if we find a nice solution, I would implement it...
>
> You can leave. But do you want to have more CPU load, more Flash IO,
> faster flash wear, more lost data after Unclean reboot?
>
> If no, make wbuf_size = DataFlash page size. And IMO, it is *MUST* for
> CVS commit.
>
But in this case mtd_info structure has to be changed/extended.
Otherwise the information does not get to the jffs2 layer. How
should/could this be managed?
>
>>IMHO the cleanest solution would be, that the dataflash/mtd layer
>>reports it's true erase_size = smallest write size = 528/1056 bytes, and
>>should not make a further guess about later use.
>
Problem is here, how does the user get the information about the erase
size used by jffs2?
> I thinks the cleanest if it reports *both* sizes. Let the upper (above
> MTD) layers decide what erasesize to use.
>
Are these two values typically existing? In the dataflash case, it's
only one value.
If they make sense, we have a write_chunk_size, and an erasesize size...
>>-#ifndef CONFIG_JFFS2_FS_WRITEBUFFER
>>+/*
>> #define SECTOR_ADDR(x) ( ((unsigned long)(x) & ~(c->sector_size-1)) )
>>+*/
>
> What for this comment ?
gets out (I commented out instead of removing)
>>- if (SECTOR_ADDR(to) != SECTOR_ADDR(c->wbuf_ofs)) {
>>+ if (PAGE_DIV(to) != PAGE_DIV(c->wbuf_ofs)) {
> Why this change ?
c->sector_size != c->wbuf_ofs
>> if (!c->mtd->block_markbad)
>>- return 1; // What else can we do?
>>+ return 1;
>
> Why this change ?
C++ comment
>
>>diff -urN mtda/drivers/mtd/mtdpart.c mtdb/drivers/mtd/mtdpart.c
>>--- mtda/drivers/mtd/mtdpart.c 2005-02-08 18:11:13.000000000 +0100
>>+++ mtdb/drivers/mtd/mtdpart.c 2005-09-14 13:20:18.000000000 +0200
>>@@ -465,8 +465,9 @@
>
> I think this is better to send as a distinct patch.
>
OK
Best regards
Peter
--
Peter Menzebach
Menzebach und Wolff IT-Consulting GbR
Phone +49 751 355 387 1
next prev parent reply other threads:[~2005-09-22 13:32 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-14 12:09 data loss on jffs2 filesystem on dataflash Peter Menzebach
2005-09-14 12:30 ` Artem B. Bityuckiy
2005-09-14 13:43 ` Peter Menzebach
2005-09-15 7:48 ` Artem B. Bityuckiy
2005-09-15 7:39 ` Peter Menzebach
2005-09-15 7:49 ` Artem B. Bityuckiy
2005-09-15 7:53 ` Artem B. Bityuckiy
[not found] ` <43292AC6.40809@mw-itcon.de>
[not found] ` <43292E16.70401@yandex.ru>
[not found] ` <43292F91.9010302@mw-itcon.de>
2005-09-20 10:18 ` Artem B. Bityutskiy
[not found] ` <432FEF55.5090700@mw-itcon.de>
2005-09-20 11:21 ` Artem B. Bityutskiy
2005-09-20 12:55 ` Artem B. Bityutskiy
2005-09-20 13:18 ` Artem B. Bityutskiy
2005-09-20 13:38 ` Peter Menzebach
2005-09-20 14:18 ` Artem B. Bityutskiy
2005-09-20 15:01 ` Peter Menzebach
2005-09-20 15:11 ` Andrew Victor
2005-09-20 15:22 ` Jörn Engel
2005-09-20 16:31 ` Artem B. Bityutskiy
2005-09-21 7:21 ` Andrew Victor
2005-09-21 9:25 ` Artem B. Bityutskiy
2005-09-21 10:27 ` Peter Menzebach
2005-09-21 13:36 ` Artem B. Bityutskiy
2005-09-21 13:41 ` Artem B. Bityutskiy
2005-09-21 15:44 ` Peter Menzebach
2005-09-21 15:59 ` Artem B. Bityutskiy
2005-09-21 16:10 ` Peter Menzebach
2005-09-21 16:19 ` Artem B. Bityutskiy
2005-09-21 17:10 ` Peter Menzebach
2005-09-22 10:38 ` Peter Menzebach
2005-09-22 10:51 ` Artem B. Bityutskiy
2005-09-20 15:11 ` Artem B. Bityutskiy
2005-09-20 15:45 ` Peter Menzebach
2005-09-20 13:32 ` Jörn Engel
2005-09-20 14:11 ` Artem B. Bityutskiy
2005-09-20 14:36 ` Jörn Engel
2005-09-20 14:48 ` Artem B. Bityutskiy
2005-09-21 19:07 ` Pavel Machek
2005-09-22 10:48 ` Artem B. Bityutskiy
2005-09-22 16:46 ` Valdis.Kletnieks
2005-09-22 17:03 ` Artem B. Bityutskiy
2005-09-22 17:22 ` linux-os (Dick Johnson)
2005-09-22 18:43 ` jscottkasten
2005-09-23 8:51 ` Jörn Engel
2005-09-22 11:34 ` Jörn Engel
2005-09-22 11:54 ` Jörn Engel
2005-09-20 13:16 ` Artem B. Bityutskiy
2005-09-15 8:02 ` Artem B. Bityuckiy
[not found] ` <43292E94.4020702@mw-itcon.de>
2005-09-15 8:26 ` Artem B. Bityuckiy
2005-09-15 8:33 ` Peter Menzebach
2005-09-15 8:47 ` Artem B. Bityuckiy
2005-09-15 9:14 ` Peter Menzebach
2005-09-15 9:25 ` Artem B. Bityuckiy
2005-09-21 13:55 ` Peter Menzebach
2005-09-21 13:59 ` Artem B. Bityutskiy
2005-09-15 10:32 ` Artem B. Bityuckiy
2005-09-22 12:30 ` Peter Menzebach
2005-09-22 12:44 ` Artem B. Bityutskiy
2005-09-22 13:31 ` Peter Menzebach [this message]
2005-09-22 14:06 ` Artem B. Bityutskiy
2005-09-22 14:32 ` Andrew Victor
2005-09-22 14:45 ` Artem B. Bityutskiy
2005-09-22 14:59 ` Peter Menzebach
2005-09-22 16:14 ` Peter Menzebach
2005-09-22 17:09 ` Peter Menzebach
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=4332B24F.2050305@mw-itcon.de \
--to=pm@mw-itcon.de \
--cc=dedekind@infradead.org \
--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.