jffs2 vs. ext3

jffs2 vs. ext3

[Siddharth Choudhuri]

I am trying jffs2 and ext3 on a 3MB Intel NOR flash. I have a piece of
code in function part_write (mtdpart.c) that outputs the size in bytes and pid
of the process (current) sending write requests.

With ext3, no matter how many bytes are written (by an application/user
level program), the part_write function always gets a request that is
multiple of 128K (131072 bytes). This does not happen with jffs2 though.
Also, with ext3, the process is always mtdblockd, whereas with jffs2 the
process sending the request is the actual user/application process.

Any ideas why it happens ?

thanks in advance,
-siddharth

_____________________________________________________________________
     Unix is user friendly - its just picky about its friends.
_____________________________________________________________________

Re: jffs2 vs. ext3

[David Woodhouse]

On Wed, 2003-06-11 at 17:03, Siddharth Choudhuri wrote:
> I am trying jffs2 and ext3 on a 3MB Intel NOR flash. I have a piece of
> code in function part_write (mtdpart.c) that outputs the size in bytes and pid
> of the process (current) sending write requests.
> 
> With ext3, no matter how many bytes are written (by an application/user
> level program), the part_write function always gets a request that is
> multiple of 128K (131072 bytes). This does not happen with jffs2 though.
> Also, with ext3, the process is always mtdblockd, whereas with jffs2 the
> process sending the request is the actual user/application process.
> 
> Any ideas why it happens ?

The flash chip has an erase size of 128KiB. You can't treat it like a
normal hard drive -- to use a traditional file system like ext3, you
have to have some kind of 'translation layer' to fake that behaviour.

The 'mtdblock' translation layer which you seem to be using is the most
naïve implementation possible of such a thing -- every time a 512-byte
sector on the 'virtual' block device is changed, we read the 128KiB
block of flash into memory, modify 512 bytes of it accordingly and then
write back the modified data.

If you lose power during the period between the erase starting and the
writeback of the modified data completing, you lose a huge chunk of your
data.

(OK, it's actually a little more intelligent than that and does combine
subsequent writes into the same eraseblock, rather than doing an erase
for _every_ 512-byte sector write, but the principle is the same, and
it's still entirely unsafe.)

There are other, more complex, translation layers such as FTL -- these
are a kind of pseudo-filesystem which emulate a block device slightly
more safely and do give you powerfail-protection by having some kind of
journalling built-in. 

When combined with a true journalling file system atop their 'virtual'
block device, that's really not the most efficient use of the flash. 

JFFS2, on the other hand, works directly with the flash and does not
suffer the same problems.

-- 
dwmw2

Re: jffs2 vs. ext3

[Siddharth Choudhuri]

> JFFS2, on the other hand, works directly with the flash and does not
> suffer the same problems.

Yes, I noticed that with JFFS2, the size (in bytes) of write requests sent
to NOR chips were not in any multiples (as opposed to ext3). For eg:
`touch filename` -or- `echo "abcd" > foo` would send multiple write
requests totalling to around 200-300 bytes.

>From what I understand, NOR chips are byte level programmable, but
changing a 0->1 would require entire block erase which might take around 1
sec. But it did not seem to happen in the above case of creating a file ?
Am I missing something basic here ?

Also, another question that I have is "Is there any reason(s) why one
should use ext3 as opposed to jffs2 on flash based systems"

TIA
-siddharth

Re: jffs2 vs. ext3

[George G. Davis]

Siddharth Choudhuri wrote:
> I am trying jffs2 and ext3 on a 3MB Intel NOR flash. I have a piece of
> code in function part_write (mtdpart.c) that outputs the size in bytes and pid
> of the process (current) sending write requests.
> 
> With ext3, no matter how many bytes are written (by an application/user
> level program), the part_write function always gets a request that is
> multiple of 128K (131072 bytes). This does not happen with jffs2 though.
> Also, with ext3, the process is always mtdblockd, whereas with jffs2 the
> process sending the request is the actual user/application process.
> 
> Any ideas why it happens ?

... also with ext3, you'll have a brick(TM) pretty soon too. ; )
Hint: ext3 doesn't not do flash wear levelling. You'll burn out
your flash chips pretty soon.

--
Regards,
George

> 
> thanks in advance,
> -siddharth
> 
> _____________________________________________________________________
>      Unix is user friendly - its just picky about its friends.
> _____________________________________________________________________
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 
> 
>