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: 51+ 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 13:16 ` Artem B. Bityutskiy
[not found] ` <433006D8.4010502@yandex.ru>
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
[not found] ` <20050920133244.GC4634@wohnheim.fh-wedel.de>
[not found] ` <43301877.3040306@yandex.ru>
2005-09-20 14:36 ` Jörn Engel
2005-09-20 14:48 ` 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox