[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Endurance

msundius@xxxxxxx.com said:
> Does JFFS2 do this check? does it take so long?

JFFS2 writes a marker to the beginning of a block when it's successfully 
erased - and just re-erases any block which _looks_ empty but doesn't have 
the marker. So it doesn't need to do the same kind of check.

> 2) Does JFFS or JFFS2 support "holes" in files? that is, can you seek
> past the end of a file and write data. This, I understand, is used to
> write core files and other sparsly populated data arrays to save
> space.

JFFS2 certainly does. I believe JFFS does too.

> 3) When I last was working w/ this stuff, it seemed as though JFFS was
> a little bit more stable and tested than JFFS2. I ended up using JFFS
> for that reason. What is the case now? I understand that JFFS2
> compresses its data, are there any other significant features/gotchas
> that make me use one over the other?

Wear levelling should be better, because we treat erase blocks individually 
rather than writing sequentially through the entire chip, 
garbage-collecting even blocs which contina only clean data just because 
they're in the way. Also, JFFS2 does hard links and attempts to be nicer 
w.r.t. memory usage. For more detail, see the paper linked from 
http://sources.redhat.com/jffs2/ (or come to linux.conf.au).

> 4) In JFFS2 is there an option to turn off the compression if need be?
> what sort of (data size/ speed) performance tradeoffs do people see
> with this..... 

The mechanism exists - we have a space in the inode info to say that the 
user didn't want the file compressed. We haven't yet actually implemented 
the ioctl for setting it, or the checking - it's not hard to do so, though.


To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo@xxxxxxx.com