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

RE: New jffs2 files stay uncompressed?

> joakim.tjernlund@xxxxxxx.se said:
> > 
> >  How? I figure that iff ACCURATE bit is set in a CLEANMARKER, then 
> >  that erase block is empty. On first write to such a EB, clear
> > ACCURATE bit in the CLEANMARKER node and then write you data to flash.
> > Can't see how to do that in jffs2_mark_node_obsolete() 
> You don't do that in jffs2_mark_node_obsolete(). But it does allow you to 
> get rid of the change you wanted to introduce to jffs2_mark_node_obsolete():
> -	} else if (!jeb->used_size) {
> +	} else if ((jeb->used_size == PAD(sizeof(struct jffs2_unknown_node)) && !jeb->first_node->next_in_ino)

Yes, is the above test the only reliable test to test for a CLEANMARKER?

BTW, I just realized the above if statement needs both checks, since there can be an EB without CLEANMARKER as well.

Another thing: Would it not be safe to skip CRC checks on the data in inodes that don't have the ACCURATE bit set
in scan.c?

> ... because you know that the CLEANMARKER node will be obsoleted, and hence 
> used_size will be zero.
> However, you can't necessarily rely on the CLEANMARKER node being marked 
> obsolete on the flash, by having the ACCURATE bit removed - not all 
> hardware supports that. I suppose for that hardware we can just do the scan 
> completely as we do today, so that's not too much of a problem.

Yes, HW that dont support that could have the ACCURATE bit removed when the
CLEANMARKER is first written to an EB. That would only disable the optmization, would it not?


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