root jffs2

root jffs2

[Xavier DEBREUIL]

I have managed to mount the jffs2 as root filesystem (yes I know many
did it but I encountered problems here and there...)
Nevertheless, some kernel messages are a little amazing :

(root=1F01 and not root=/dev/mtdblock1...)

...
root_device_name : 1F01
mtdblock_open
ok
mtdblock: read on "cramfs partition" at 0x400, size 0x400
mtdblock: read on "cramfs partition" at 0x0, size 0x1000
mtdblock: read on "cramfs partition" at 0x1000, size 0x1000
mtdblock: read on "cramfs partition" at 0x2000, size 0x1000
mtdblock: read on "cramfs partition" at 0x3000, size 0x1000
wrong magic
JFFS: Trying to mount device 1f:01.
jffs_build_fs()
jffs_create_control()
jffs_scan_flash(): start pos = 0x0, end = 0x300000
check_partly_erased_sector():checking sector which contains offset 0x0
for flipping bits..
check_partly_erased_sector():checking sector which contains offset
0x1000 for flipping bits..
...
blahblah...
...
check_partly_erased_sector():Done checking all sectors till offset
0x300000 for flipping bits.
*************** Dirty flash memory or bad inode: hexdump(pos = 0x0, len
= 128):
0: 8519 02e0 4400 0000 1dfb f798 0100 0000  ...àD....û÷.....
16: 0100 0000 ed41 0000 f501 f501 0000 0000  ....íA..õ.õ.....
32: de1d 1d3b 4228 263b 4228 263b 0000 0000  Þ..;B(&;B(&;....
48: 0000 0000 0000 0000 0000 0000 0000 0000  ................
64: 3c72 4031 8519 01e0 2b00 0000 e66e 267d  <r@1...à+...æn&}
80: 0100 0000 0200 0000 0200 0000 4228 263b  ............B(&;
96: 0304 0000 5f5a ae8b dee2 4e56 6c69 62ff  ...._Z®.ÞâNVlibÿ
112: 8519 02e0 4400 0000 1dfb f798 0200 0000  ...àD....û÷.....
jffs_scan_flash(): 0xffffffff at pos 0x11afc.
jffs_scan_flash():0xffffffff ended at pos 0x11b00.
Dirty space: Starting 0x11afc for 0x4 bytes
*************** Dirty flash memory or bad inode: hexdump(pos = 0x11b00,
len = 128):
72448: 8519 01e0 3100 0000 1dd9 8242 0200 0000  ...à1....Ù.B....
72464: 0900 0000 0a00 0000 eb1d 1d3b 090a 0000  ........ë..;....
...

seems that many things are dirty though I have never mounted it
before...

...
jffs_scan_flash(): 0xffffffff at pos 0x2e000c.
jffs_scan_flash():0xffffffff ended at pos 0x300000.
Free space (#24) found but *Not* accepted: Starting 0x2e000c for 0x1fff4
bytes
Dirty space: Starting 0x2e000c for 0x1fff4 bytes
jffs_scan_flash(): Did not find even a single chunk of free space. This
is BAD!
jffs_scan_falsh():Free size accounting screwed
jfffs_scan_flash():free_chunk_size1 == 0x300000, free_chunk_size2 ==
0x0, fmc->free_size == 0x0
jffs_cleanup_control()
----> !!!!!
----> JFFS: Failed to mount device 1f:01.
----> VFS: Mounted root (jffs2 filesystem) readonly.
----> !!!!!
Freeing init memory: 48K
serial console detected.  Disabling virtual terminals.
init started:  BusyBox v0.51 (2001.06.05-17:42+0000) multi-call binary


So, on the one hand, it indicates that it failed to mount the device on
1F01 but afterwards, it managed to mount the jffs2 filesystem as root
fs. Is it a known behaviour or do I have to modify some parameters ?

Xavier
\x01\x01\x01

Re: root jffs2

[Xavier DEBREUIL]

> ----> !!!!!
> ----> JFFS: Failed to mount device 1f:01.
> ----> VFS: Mounted root (jffs2 filesystem) readonly.
> ----> !!!!!
> Freeing init memory: 48K
> serial console detected.  Disabling virtual terminals.
> init started:  BusyBox v0.51 (2001.06.05-17:42+0000) multi-call binary
> 
> So, on the one hand, it indicates that it failed to mount the device on
> 1F01 but afterwards, it managed to mount the jffs2 filesystem as root
> fs. Is it a known behaviour or do I have to modify some parameters ?
> 

In fact, when the JFFS says that it failed to mount the device 1f:01,
the VFS detects the jffs2 and mount it ; and when it successfully
mounted device 1f:01, VFS mounts a jffs filesystem ; but as it is a
jffs2, then the following happens !!!

JFFS: Successfully mounted device 1f:01.
VFS: Mounted root (jffs filesystem) readonly.
Freeing init memory: 48K
Warning: unable to open an initial console.
Kernel panic: No init found.  Try passing init= option to
kernel.                                                                             

Any help is welcomed

Xavier

Re: root jffs2

[David Woodhouse]

xde@inventel.fr said:
>  In fact, when the JFFS says that it failed to mount the device 1f:01,
> the VFS detects the jffs2 and mount it ; and when it successfully
> mounted device 1f:01, VFS mounts a jffs filesystem ; but as it is a
> jffs2, then the following happens !!!

Disable JFFS and compile in only JFFS2.

--
dwmw2

Re: root jffs2

[Xavier DEBREUIL]

David Woodhouse a écrit :
> 
> xde@inventel.fr said:
> >  In fact, when the JFFS says that it failed to mount the device 1f:01,
> > the VFS detects the jffs2 and mount it ; and when it successfully
> > mounted device 1f:01, VFS mounts a jffs filesystem ; but as it is a
> > jffs2, then the following happens !!!
> 
> Disable JFFS and compile in only JFFS2.
> 
> --
> dwmw2


Sorry for that early posting ; that's what I was doing and it works for
now.

Thank you.

Xavier

Re: root jffs2

[Vipin Malik]

I read the messages where you solved this problem, but let me add a side
note just for future reference:

JFFS can *NOT* be mounted on a device that has either 1. Not been erased OR
2. Not been initialized with
a JFFS image (using the external tool).

That is why it finds all those "dirty" sectors and no free space.

On the other hand, JFFS2 *can* be mounted on a device that has not been
initialized. It will detect the
"dirty" sectors and just format them- resulting in a blank fs the first
time you mount it.

This also means that if you accidentally mount a JFFS2 fs on a device that
has an existing JFFS fs on it
it will format the entire device- without warning!

Vipin





Xavier DEBREUIL wrote:

> I have managed to mount the jffs2 as root filesystem (yes I know many
> did it but I encountered problems here and there...)
> Nevertheless, some kernel messages are a little amazing :
>
> (root=1F01 and not root=/dev/mtdblock1...)
>
> ...
> root_device_name : 1F01
> mtdblock_open
> ok
> mtdblock: read on "cramfs partition" at 0x400, size 0x400
> mtdblock: read on "cramfs partition" at 0x0, size 0x1000
> mtdblock: read on "cramfs partition" at 0x1000, size 0x1000
> mtdblock: read on "cramfs partition" at 0x2000, size 0x1000
> mtdblock: read on "cramfs partition" at 0x3000, size 0x1000
> wrong magic
> JFFS: Trying to mount device 1f:01.
> jffs_build_fs()
> jffs_create_control()
> jffs_scan_flash(): start pos = 0x0, end = 0x300000
> check_partly_erased_sector():checking sector which contains offset 0x0
> for flipping bits..
> check_partly_erased_sector():checking sector which contains offset
> 0x1000 for flipping bits..
> ...
> blahblah...
> ...
> check_partly_erased_sector():Done checking all sectors till offset
> 0x300000 for flipping bits.
> *************** Dirty flash memory or bad inode: hexdump(pos = 0x0, len
> = 128):
> 0: 8519 02e0 4400 0000 1dfb f798 0100 0000  ...àD....û÷.....
> 16: 0100 0000 ed41 0000 f501 f501 0000 0000  ....íA..õ.õ.....
> 32: de1d 1d3b 4228 263b 4228 263b 0000 0000  Þ..;B(&;B(&;....
> 48: 0000 0000 0000 0000 0000 0000 0000 0000  ................
> 64: 3c72 4031 8519 01e0 2b00 0000 e66e 267d  <r@1...à+...æn&}
> 80: 0100 0000 0200 0000 0200 0000 4228 263b  ............B(&;
> 96: 0304 0000 5f5a ae8b dee2 4e56 6c69 62ff  ...._Z®.ÞâNVlibÿ
> 112: 8519 02e0 4400 0000 1dfb f798 0200 0000  ...àD....û÷.....
> jffs_scan_flash(): 0xffffffff at pos 0x11afc.
> jffs_scan_flash():0xffffffff ended at pos 0x11b00.
> Dirty space: Starting 0x11afc for 0x4 bytes
> *************** Dirty flash memory or bad inode: hexdump(pos = 0x11b00,
> len = 128):
> 72448: 8519 01e0 3100 0000 1dd9 8242 0200 0000  ...à1....Ù.B....
> 72464: 0900 0000 0a00 0000 eb1d 1d3b 090a 0000  ........ë..;....
> ...
>
> seems that many things are dirty though I have never mounted it
> before...
>
> ...
> jffs_scan_flash(): 0xffffffff at pos 0x2e000c.
> jffs_scan_flash():0xffffffff ended at pos 0x300000.
> Free space (#24) found but *Not* accepted: Starting 0x2e000c for 0x1fff4
> bytes
> Dirty space: Starting 0x2e000c for 0x1fff4 bytes
> jffs_scan_flash(): Did not find even a single chunk of free space. This
> is BAD!
> jffs_scan_falsh():Free size accounting screwed
> jfffs_scan_flash():free_chunk_size1 == 0x300000, free_chunk_size2 ==
> 0x0, fmc->free_size == 0x0
> jffs_cleanup_control()
> ----> !!!!!
> ----> JFFS: Failed to mount device 1f:01.
> ----> VFS: Mounted root (jffs2 filesystem) readonly.
> ----> !!!!!
> Freeing init memory: 48K
> serial console detected.  Disabling virtual terminals.
> init started:  BusyBox v0.51 (2001.06.05-17:42+0000) multi-call binary
>
> So, on the one hand, it indicates that it failed to mount the device on
> 1F01 but afterwards, it managed to mount the jffs2 filesystem as root
> fs. Is it a known behaviour or do I have to modify some parameters ?
>
> Xavier
> \x01\x01\x01
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: root jffs2

[Nicolas Pitre]

On Wed, 13 Jun 2001, Vipin Malik wrote:

> I read the messages where you solved this problem, but let me add a side
> note just for future reference:
>
> JFFS can *NOT* be mounted on a device that has either 1. Not been erased OR
> 2. Not been initialized with
> a JFFS image (using the external tool).
>
> That is why it finds all those "dirty" sectors and no free space.
>
> On the other hand, JFFS2 *can* be mounted on a device that has not been
> initialized. It will detect the
> "dirty" sectors and just format them- resulting in a blank fs the first
> time you mount it.
>
> This also means that if you accidentally mount a JFFS2 fs on a device that
> has an existing JFFS fs on it
> it will format the entire device- without warning!

This behavior was modified recently.  If JFFS2 finds dirty blocks without a
single valid JFFS2 node on the flash it won't erase it and refuse to mount.


Nicolas

Re: root jffs2

[Vipin Malik]

> > This also means that if you accidentally mount a JFFS2 fs on a device that
> > has an existing JFFS fs on it
> > it will format the entire device- without warning!
>
> This behavior was modified recently.  If JFFS2 finds dirty blocks without a
> single valid JFFS2 node on the flash it won't erase it and refuse to mount.
>

Does this mean that you can no longer mount JFFS2 on an erased (blank) flash mtd
device and
hand populate the blank fs ?

If so, then I lodge my official protest!

Vipin

Re: root jffs2

[Nicolas Pitre]

On Wed, 13 Jun 2001, Vipin Malik wrote:

> > > This also means that if you accidentally mount a JFFS2 fs on a device that
> > > has an existing JFFS fs on it
> > > it will format the entire device- without warning!
> >
> > This behavior was modified recently.  If JFFS2 finds dirty blocks without a
> > single valid JFFS2 node on the flash it won't erase it and refuse to mount.
> >
>
> Does this mean that you can no longer mount JFFS2 on an erased (blank) flash mtd
> device and
> hand populate the blank fs ?

A blank flash isn't considered dirty.


Nicolas

Re: root jffs2

[David Woodhouse]

vipin.malik@daniel.com said:
>  Does this mean that you can no longer mount JFFS2 on an erased
> (blank) flash mtd device and hand populate the blank fs ?

It refuses to mount if it would be erasing some blocks to start with and
it's found no valid nodes. Thinks.... if the device is completely 
pre-erased then it'd be erasing every block 'to make sure', so it'd fail to 
mount. 

We could special-case this - if the device _was_ entirely empty beforehand 
- if it contained only 0xFF, then we can go ahead with the mount. Only if 
it actually had some data on should we fail.

> If so, then I lodge my official protest!

Protests are only accepted in 'diff -u' form. :)


--
dwmw2

Re: root jffs2

[David Woodhouse]

nico@cam.org said:
>  A blank flash isn't considered dirty.

Any block which doesn't contain the CLEANMARKER node at the beginning is 
considered dirty.

--
dwmw2

Re: root jffs2

[Nicolas Pitre]

On Wed, 13 Jun 2001, David Woodhouse wrote:

>
> vipin.malik@daniel.com said:
> >  Does this mean that you can no longer mount JFFS2 on an erased
> > (blank) flash mtd device and hand populate the blank fs ?
>
> It refuses to mount if it would be erasing some blocks to start with and
> it's found no valid nodes. Thinks.... if the device is completely
> pre-erased then it'd be erasing every block 'to make sure', so it'd fail to
> mount.

That's not what I though...

> We could special-case this - if the device _was_ entirely empty beforehand
> - if it contained only 0xFF, then we can go ahead with the mount. Only if
> it actually had some data on should we fail.

Exactly.


Nicolas

Re: root jffs2

[Vipin Malik]

David Woodhouse wrote:

> > If so, then I lodge my official protest!
>
> Protests are only accepted in 'diff -u' form. :)
>

David, that's an easy one. I'll just do a:

$diff -u <new_version_that's_broken>   <old_version_that_worked>

;)

More seriously, Nicolas just wrote that blank flash is not considered dirty
and one can still mount a JFFS2 fs on it and hand populate it.

Do you concur?

Vipin

Re: root jffs2

[Nicolas Pitre]

On Wed, 13 Jun 2001, Vipin Malik wrote:

> More seriously, Nicolas just wrote that blank flash is not considered dirty
> and one can still mount a JFFS2 fs on it and hand populate it.

That was my belief.  It seemed logical.  I was aparently wrong.  I too
consider it a bug if it isn't that way.


Nicolas

Re: root jffs2

[David Woodhouse]

vipin.malik@daniel.com said:
>  David, that's an easy one. I'll just do a:
> $diff -u <new_version_that's_broken>   <old_version_that_worked>
> ;)


Where "broken" just isn't particularly convenient for you, and "worked" is 
the version that would wipe a cramfs root filesystem if jffs2 happened to 
be linked into the kernel first.

Quick way to get your CVS access revoked, that one :)

> More seriously, Nicolas just wrote that blank flash is not considered
> dirty and one can still mount a JFFS2 fs on it and hand populate it.

> Do you concur? 

No, we treat any block which is completely empty and doesn't contain a 
cleanmarker as dirty, because we can't be sure it was properly erased. 

How about changing the if(!c->used_size) at line 133 of scan.c to 
if(c->dirty_size) ?

Thinks... are we getting the accounting right in that case anyway? Why 
doesn't the final else case (/* Nothing valid... ) a few lines above change 
free_size?

--
dwmw2

Re: root jffs2

[David Woodhouse]

nico@cam.org said:
>  That was my belief.  It seemed logical.  I was aparently wrong.  I
> too consider it a bug if it isn't that way.

Agreed. But the alternative bug - erasing the whole device if we tried to 
mount as jffs2 by mistake - was worse. 

--
dwmw2

Re: root jffs2

[Nicolas Pitre]

On Wed, 13 Jun 2001, David Woodhouse wrote:

>
> nico@cam.org said:
> >  That was my belief.  It seemed logical.  I was aparently wrong.  I
> > too consider it a bug if it isn't that way.
>
> Agreed. But the alternative bug - erasing the whole device if we tried to
> mount as jffs2 by mistake - was worse.

Indeed.


Nicolas

Re: root jffs2

[Vipin Malik]

What about a "jffs2erase" routine that not only erases the flash sectors but
also writes out this
"signature" at the start of every erase block. This way one can mount an
empty JFFS2 fs on
a MTD partition erased by jffs2erase?

Vipin




David Woodhouse wrote:

> nico@cam.org said:
> >  That was my belief.  It seemed logical.  I was aparently wrong.  I
> > too consider it a bug if it isn't that way.
>
> Agreed. But the alternative bug - erasing the whole device if we tried to
> mount as jffs2 by mistake - was worse.
>
> --
> dwmw2

Re: root jffs2

[Nicolas Pitre]

On Wed, 13 Jun 2001, Vipin Malik wrote:

> What about a "jffs2erase" routine that not only erases the flash sectors but
> also writes out this
> "signature" at the start of every erase block. This way one can mount an
> empty JFFS2 fs on
> a MTD partition erased by jffs2erase?

This is IMHO not the real solution.


Nicolas

Re: root jffs2

[David Woodhouse]

nico@cam.org said:
>  On Wed, 13 Jun 2001, Vipin Malik wrote:
> > What about a "jffs2erase" routine that not only erases the flash sectors
> > but also writes out this "signature" at the start of every erase block.
> > This way one can mount an empty JFFS2 fs on a MTD partition erased by 
> > jffs2erase?

> This is IMHO not the real solution.

Why? No other filesystem can be mounted on empty media without some form of 
mkfs.

In fact you wouldn't need to do every block. All you'd have to do is put 
the 12-byte cleanmarker node at the beginning of the first block and it'd 
be sufficient. 

You could do this with a suitable 'echo' command.


--
dwmw2

Re: root jffs2

[Nicolas Pitre]

On Wed, 13 Jun 2001, David Woodhouse wrote:

>
> nico@cam.org said:
> >  On Wed, 13 Jun 2001, Vipin Malik wrote:
> > > What about a "jffs2erase" routine that not only erases the flash sectors
> > > but also writes out this "signature" at the start of every erase block.
> > > This way one can mount an empty JFFS2 fs on a MTD partition erased by
> > > jffs2erase?
>
> > This is IMHO not the real solution.
>
> Why? No other filesystem can be mounted on empty media without some form of
> mkfs.

JFFS2 is far from being a conventional filesystem, no?

It is really elegant to just erase the flash partition and mount right away.
Not yet another special tool please.

> In fact you wouldn't need to do every block. All you'd have to do is put
> the 12-byte cleanmarker node at the beginning of the first block and it'd
> be sufficient.

This is ugly.

> You could do this with a suitable 'echo' command.

This is ridiculous, especially when the fix is probably about a one or two
line change in JFFS2 code.  I'm currently looking at it.  Expect the diff
soon.

Let's avoid the hassle of requiring people to need yet another tool.


Nicolas

Re: root jffs2

[Vipin Malik]

> This is ridiculous, especially when the fix is probably about a one or two
> line change in JFFS2 code.  I'm currently looking at it.  Expect the diff
> soon.
>
> Let's avoid the hassle of requiring people to need yet another tool.

You are a good man :)

Vipin

Re: root jffs2

[Nicolas Pitre]

On Wed, 13 Jun 2001, David Woodhouse wrote:

>
> nico@cam.org said:
> >  That was my belief.  It seemed logical.  I was aparently wrong.  I
> > too consider it a bug if it isn't that way.
>
> Agreed. But the alternative bug - erasing the whole device if we tried to
> mount as jffs2 by mistake - was worse.

Just committed a patch to allow mounting JFFS2 on entirely empty (erased)
flash.  It should speed up the mount of partially erased partitions as well
since the empty blocks aren't erased unnecessarily anymore.


Nicolas

Re: root jffs2

[Vipin Malik]

> Just committed a patch to allow mounting JFFS2 on entirely empty (erased)
> flash.  It should speed up the mount of partially erased partitions as well
> since the empty blocks aren't erased unnecessarily anymore.
>

I hope you have accounted for "flipping bits" (TM Vipin Malik) sectors.
That's why the start of erase-sector signature was introduced in the first
place.

If a sector does not have the signature it *must be erased* even if you read
0xff from
all locations in the sector. Just writing the signature is not enough.

And of course, this signature must be invalidated before going in to erase the
sector so that
if power fails in the middle of the erase, the sector ends up being erased on
the next mount.

If you don't do this, "flipping bits" will come up behind you and nip you in
the bud :)

Vipin

Re: root jffs2

[Nicolas Pitre]

On Wed, 13 Jun 2001, Vipin Malik wrote:

> > Just committed a patch to allow mounting JFFS2 on entirely empty (erased)
> > flash.  It should speed up the mount of partially erased partitions as well
> > since the empty blocks aren't erased unnecessarily anymore.
> >
>
> I hope you have accounted for "flipping bits" (TM Vipin Malik) sectors.
> That's why the start of erase-sector signature was introduced in the first
> place.

If a sector is empty, it is simply put in the queue for signature stamping.

> If a sector does not have the signature it *must be erased* even if you read
> 0xff from
> all locations in the sector. Just writing the signature is not enough.

What do you mean by that?

> And of course, this signature must be invalidated before going in to erase the
> sector so that
> if power fails in the middle of the erase, the sector ends up being erased on
> the next mount.

If that's really necessary to re-erase them even if they are already erased
then it's just a matter of replacing "erase_complete_list" by
"erase_pending_list"  on line 97 of fs/jffs2/scan.c.

> If you don't do this, "flipping bits" will come up behind you and nip you in
> the bud :)

Please could you enlighten me on the matter?


Nicolas

Re: root jffs2

[David Woodhouse]

nico@cam.org said:
>  If a sector is empty, it is simply put in the queue for signature
> stamping. 

It's easier to erase it again than prove it's empty. Reading the whole 
thing ten times wasn't sufficient - an improperly erased bit could return a 
zero on the eleventh read, after the whole device was reading 0xFF on the ten 
previous reads.

The erases aren't done synchronously - they're done in the background. They 
shouldn't hold the mount up. I suspect the patch you committed will make it 
start failing Vipin's powerfail tests again.

--
dwmw2

Re: root jffs2

[Vipin Malik]

> If a sector is empty, it is simply put in the queue for signature stamping.

How do you know it's empty? Just because you read 0xff from it? It could be
partially erased!

>
> > If you don't do this, "flipping bits" will come up behind you and nip you in
> > the bud :)
>
> Please could you enlighten me on the matter?

The story of flipping bits goes as follows:

Once upon a time in a land far far away (ok just a few offices down :), I was
testing the JFFS file system for power down
reliability.

Occasionally the system would run out of kernel memory, even though there was no
logical way for that
to happen in the mount logic. Basically it turned out that if power failed just at
the right time during the erase
of a sector, the next time you read the sector, the data read back would not be
consistent across multiple reads!

In other words, there would be bits in that sector that would "flip" from 1 to 0 or
from 0 to 1. There is no way to detect
these by reading the sector.

Sometimes you can read the sector 2 times and read 0xff all the way through. Then
on the 3rd read a few bits may come back as "0"!

The only reliable solution is an algorithmic one. I first saw it suggested by Alan
Cox. It goes as follows:

<Inspect sector>
<verify magic sector signature>
<erase sector if no signature *regardless of state of data in it*>
<write signature>
<manupliate data in sector>
...
<more manuplitations of data in sector. Magic signature remains in place.>
...
/* Now you (GC) want to erase the sector */
<Invalidate the signature by overwriting it>  <-If pwr fails at this point, the
sector will be erased on next mount => as desired
<erase the sector>    <- If pwr fails here and we get flipping bits, magic sig will
be missing => sector reerased.
<sector erase successful? => rewrite sig at head> <- if pwr fails here, no issue.
If sig good=> accept sector. If sig bad=>reerase sector.
<back to top and logic loop repeats>


In the above, nowhere do we depend on reading the sector for 0xff to determine if
it needs to be erased. That was the weak spot
and has been eliminated. The only weak link is if the gods align against you and
your flipping bits flip in such a way that
they present your magic signature back to you. Very very unlikely!

This is something important to note vs JFFS. JFFS cannot support this functionality
as it does not manage erase sectors. The only way
to detect flipping bits is to read the sector multiple times and *hope* that you
detect a change in bits in the N times you are going to
re-read it. If N is large your chances of detection is high but so is your mount
time. At the moment I've coded N to be 4 as I found that
under that there was a real chance of missing flipping bits sectors.

Vipin

P.S. Why do flipping bits happen? My theory is, as FLASH devices work by
capturing/releasing charge in a floating gate, a partially
erased sector may just have enough charge to be in the threshold region of the
sense amps. These bits may be read back as 1 or 0,
depending on the alignment of the stars and the flapping of butterfly wings in a
country across the globe.

This is an astable state and the only way to get the device back is to reerase the
sector.

P.P.S I believe that David independently discovered this problem around the same
time.

Re: root jffs2

[Nicolas Pitre]

On Wed, 13 Jun 2001, Vipin Malik wrote:

> In other words, there would be bits in that sector that would "flip" from 1 to 0 or
> from 0 to 1. There is no way to detect
> these by reading the sector.
>
> Sometimes you can read the sector 2 times and read 0xff all the way through. Then
> on the 3rd read a few bits may come back as "0"!
>
> The only reliable solution is an algorithmic one. I first saw it suggested by Alan
> Cox. It goes as follows:

[...]

OK. Remember that discussion.  I just never caught the very reason why in
the first place.

So I reverted the queueing of empty blocks for erasing, while still counting
them.  If the whole flash is empty then mounting JFFS2 is still allowed and
the whole flash will be re-erased to be on the safe side.


Nicolas

Re: root jffs2

[Vipin Malik]

Nicolas Pitre wrote:

> OK. Remember that discussion.  I just never caught the very reason why in
> the first place.
>
> So I reverted the queueing of empty blocks for erasing, while still counting
> them.  If the whole flash is empty then mounting JFFS2 is still allowed and
> the whole flash will be re-erased to be on the safe side.
>

Great.

I think we should put warning notes in the appropriate place in the code
regarding this (if not already there now), as this is one feature that at first blush
seems appropriate
for optimizing by an unsuspecting programmer, in the future.

The last thing we want is this "feature" to creep back in a few years from now when
none of us are vigilant about this.

Vipin