Strange automatic GC threshold ?

[Joakim Tjernlund]

On Mon, 2007-03-19 at 12:35 -0500, Josh Boyer wrote:
> 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 know, hence the :)

> 
> 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.

Can't be worse than current behavior as now the system becomes painfully
slow long before it starts GC. Perhaps one need one threshold to start
GC due to dirtiness and another one when to stop?

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

Sorry, but no.

> 
> josh
> 
> 
>