public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: "Artem B. Bityutskiy" <dedekind@yandex.ru>
To: Andrew Victor <andrew@sanpeople.com>
Cc: Linux MTD <linux-mtd@lists.infradead.org>,
	Peter Menzebach <pm-mtd@mw-itcon.de>
Subject: Re: data  loss on jffs2 filesystem on dataflash
Date: Wed, 21 Sep 2005 13:25:08 +0400	[thread overview]
Message-ID: <433126F4.7060904@yandex.ru> (raw)
In-Reply-To: <1127287279.25521.866.camel@fuzzie.sanpeople.com>

Andrew,

Andrew Victor wrote:
> I don't.  I set the wbuf_pagesize to the sector_size.
> (Which at that time was 1 or more eraseblocks.  And I think sector_size
> is/was the smallest unit of flash that JFFS2 would ever erase/write).
You used to think or still think :-) ?
eraseblock, which is of size = c->sector_size is the smallest JFFS2 
erase unit.
The smallest write unit is usually *smaller* then eraseblock and = 
c->wbuf_pagesize. Your DataFlash port has c->wbuf_pagesize = 
c->sector_size which is wasteful. This leads to much faster Flash wear. 
This makes unneeded loads to JFFS2. This should work, but not the best 
approach.

> Maybe there is some confusion here.  Dataflash has both 'pages' and
> 'blocks'.  With a 'page' being the smallest unit that can be
> erased/written.
Yes, but it is impossible to make JFFS2 eraseblock = DataFlash page 
size. Why? Because the page is too small. JFFS2's nodes cannot overlap 
eraseblock's borders. So, we cannot fit large 4K JFFS2 nodes to such 
small (1056 bytes) eraseblocks. Thus, the most logical approach is to 
make eraseblock size = DataFlash page size.

> 
> The MTD-device's erasesize is therefore set to the smallest unit - the
> Dataflash page size (528 or 1056, depending on device)
Well, may be this is right that *MTD* reports erasesize = DataFlash page 
size. But JFFS2 then must realize that it works on top of DataFlash and 
use blocks as erase units.

> Dataflash does not use Padding nodes.
I'm about JFFS2 - it pads wbuf. But well, it does not matter anyway. If 
your wbuf is 8K, you write there 100 byters then do sync, you wate (8K - 
100) bytes. It doen't matter whether you write padding or not. You waste 
the space, period. :-)

> Maybe it would be more optimal to set the wbuf_size to eraseblocksize? 
> I don't know.
Grrr. No! We don't understand each other at all :-)

> I do know that JFFS2-on-Dataflash was working fine when I committed the
> changes in February.
Now it doesn't :-) Sure, you don't have to fix it :-) We were just 
curious. I guess Peter should deal with this.

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.

  reply	other threads:[~2005-09-21  9:25 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 [this message]
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
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=433126F4.7060904@yandex.ru \
    --to=dedekind@yandex.ru \
    --cc=andrew@sanpeople.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=pm-mtd@mw-itcon.de \
    /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