[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 
> data.
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 majordomo@xxxxxxx.com