[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
> 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
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 email@example.com