[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: CLEANMARKER obsolete, last-ic cache.
> I've committed code to the trunk to remember the last inode_cache looked
> up, and to mark CLEANMARKER nodes obsolete in jffs2_do_reserve_space() when
> we first start to allocate from a new block.
> What I think I'll do next is preread the whole erase block at the beginning
> of jffs2_scan_eraseblock() instead of reading it all in little pieces to
> little buffers. In jffs2_scan_medium() we can vmalloc() an eraseblock-sized
> space for this. I don't think that's too evil.
Hmm, I have 256KB EB, but also plenty of RAM. This would probably
be an improvement.
> Next optimisation will be to lock the flash chip down and just use a
> pointer into the chip itself, of course - once all the actual scan code is
> set up to deal with the fact that it's just dealing with a pointer to the
no, not a direct pointer. That will bust my Burst Read. Right now I invalidate
the data cache, for the address range in question, before the copyfrom() call. I think
there has to be some sort of wrapper function.
> Your optimisation of checking for a cleanmarker and avoiding the scan for
> 0xFF will still be possible, if you can work out a way to make it reliable
> with older filesystems that didn't obsolete the cleanmarker. You just put
> that check before the large read at the beginning of jffs2_scan_eraseblock().
That will be tough, since there is no visual difference between an old CLEANMARKER
and a new CLEANMARKER. Maybe a version field in the superblock?
> Btw, there's now an IRC channel on irc.openprojects.net - #mtd.
> Semi-intelligent conversation has been known to occur there, between Thomas
> and I who are the only people on it so far.
Never tried that, I might one day though, but now I am sick and I don't get much
To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to firstname.lastname@example.org