Strange automatic GC threshold ?

[Josh Boyer]

On Mon, 2007-03-19 at 18:21 +0100, Joakim Tjernlund wrote:
> On Mon, 2007-03-19 at 12:03 -0500, Josh Boyer wrote:
> > On Mon, 2007-03-19 at 16:49 +0000, MikeW wrote:
> > > Joakim Tjernlund <joakim.tjernlund <at> transmode.se> writes:
> > > 
> > > > 
> > > > In jffs2_thread_should_wake() there is this test to
> > > > wake up GC thread:
> > > > 
> > > > 	if (c->nr_free_blocks + c->nr_erasing_blocks < c->resv_blocks_gctrigger &&
> > > > 			(dirty > c->nospc_dirty_size))
> > > > 
> > > > The && in the above if means that no matter how dirty the FS is, it wont
> > > > trigger GC until there is a very low count of free blocks as well(24 in my
> > > > case out of 1003). I wonder if that && should be a || instead?
> > > > 
> 
> How about thinking about the orginal question that made me send this
> mail in the first place before sending any patches? :)

I have been.  That response just takes more time. :)  (And the patches
comment was about adding more (), not to you specifically.)

I'd be interested to see how the behavior of GC differs with the
proposed change.  Theoretically, it seems to make sense to allow GC to
make progress and it could help the "oh crap we're out of space" grind
that seems to occur.  My biggest concern would be if it actually made GC
harder to do in the long run as the obsolete nodes could potentially get
more scattered among the eraseblocks.

Do you (or anyone else) have a setup where you could test the change
with varying cases of write frequency and usage?

josh