public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Felix Domke <tmbinc@elitedvb.net>
To: linux-mtd@lists.infradead.org
Subject: Incomplete nodes written to flash
Date: Tue, 31 Aug 2004 13:22:00 +0200	[thread overview]
Message-ID: <41345F58.4000206@elitedvb.net> (raw)

I have a 32MB NAND flash using linux-2.6.8-rc4 with a 2MB jffs2 
partition (along with a bigger jffs2 partition).

What I experience is corrupted nodes when not unmounting a jffs2 
partition properly. It seems that the last node written to flash is 
incompetely written (the last, not completely filled sector isn't written).

Unmounting writes this last sector, with correct padding. Now, is that 
the supposed behaviour?

I have, for example, a 2MB boot jffs2 partition. It only contains one 
file in mostly 4k chunks. At some boundaries, there are like ~0x98 bytes 
unused space, which is just filled with FF until the next sector. I know 
that these can't be avoided, as a chunk can never wrap around a block, 
and the remaining space is not enough to generate a new chunk.

When i now create any file on that partition, the new directory node and 
the new file node will be written, but then a garbage collection will 
start, collecting a block with these 0x98 bytes free space. Why does it 
make a GC here? Does it try to reorganize the blocks to make the 0x98 
bytes usable?

But in any case, the last sector of the last garbage collected block 
(i.e. the last sector "written") isn't physically written to the device, 
only when i unmount the filesystem. Is that supposed? I know that NAND 
has these "10 writes then you must erase" restriction, so i guess the 
last write is delayed since you can't reuse the last part of the sector 
otherwise without counting these 10 times. But in my eyes, it would be 
better to waste the remaining sector (<512 bytes) but keep data 
integrity in these cases, because otherwise you will always(!) loose 
data when turing off the device.

I know that jffs2 should ignore all nodes with wrong data crc, but i 
don't want to rely on that.

Or is there any timer which completes these writes after a certain 
timeout which just doesn't work for me?

Felix

             reply	other threads:[~2004-08-31 11:19 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-31 11:22 Felix Domke [this message]
2004-08-31 11:58 ` Incomplete nodes written to flash Josh Boyer
2004-08-31 12:14   ` Felix Domke

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=41345F58.4000206@elitedvb.net \
    --to=tmbinc@elitedvb.net \
    --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