Hi,
On Mon, 15 Mar 2010 00:03:45 +0100, David Arendt wrote:
> Hi,
>
> I am posting this again to the correct mailing list as I cc'ed it to the
> old inactive one.
>
> Maybe I am understanding something wrong, but if I would use the count
> of reclaimed segments, how could I determine if one cleaning pass has
> finished as I don't know in advance how many segments could be reclaimed ?
For example, how about this?
nmax = (number of segments) - (number of clean segments)
nblk = (max_clean_segments - (number of clean segments)) *
(number of blocks per segment)
* If (number of clean segments) < min_clean_segments, then start reclamation
* Try to reclaim nmax segments (at a maximum).
* When the cleaner found and freed nblk blocks during the
reclamation, then end one cleaning pass.
> Another approach would be not basing cleaning on a whole cleaning pass
> but instead creating these addtional configfile options:
>
> # start cleaning if less than 100 free segments
> min_clean_segments 100
>
> # stop cleaning if more than 200 free segments
> max_clean_segments 200
>
> # check free space once an hour
> segment_check_interval 3600
>
> Basically in this example if less than 800mb are free cleaner is run
> until 1600mb are free. If min_clean_segments is 0, the cleaner would do
> normal operation.
The first two parameters look Ok.
(I've already referred to these in the above example.)
We may well be able to make segment_check_interval more frequent.
or do you have something in mind?
Do you mean interval of cleaning passes ?
> For this solution only changes in configfile loading and
> nilfs_cleanerd_clean_loop would be necessary which would lower the risk
> of introducing new bugs.
>
> If this solution is ok for you, I will implement it this way and send
> you the patch in a few days. Also tell me if the names I have choosen
> for the options are ok for you or if you would prefer other ones.
The option names look fine to me.
Or should we use percentage for them?
(number of segments is device dependent)
Is there anything else that isn't clear?
> Thanks in advance
> Bye,
> David Arendt
Thanks,
Ryusuke Konishi
> On 03/14/10 15:28, Ryusuke Konishi wrote:
> > Hi,
> > On Sun, 14 Mar 2010 14:00:19 +0100, ad...@prnet.org wrote:
> >
> >> Hi,
> >>
> >> I will try to implement this myself then. Concerning the
> >> nilfs_cleanerd_select segments function I was unclear in my post. In
> >> fact I did not mean the return value but the first element from the
> >> segnums array.
> >>
> > Ok. So you thought of determining termination of one cleaning pass by
> > the segment number stored preliminarily.
> >
> > Why not just use count of processed (i.e. reclaimed) segments?
> >
> > Note that it's not guranteed that segments are selected in the order
> > of segment number though this premise looks almost right.
> >
> > It depends on the behavior of segment allocator and the current
> > "Select-oldest" algorithm used behind
> > nilfs_cleanerd_select_segments(). Nilfs log writer occasionally
> > behaves differently and disturbs this order.
> >
> > I think you can ignore the exceptional behavior of the segment
> > allocator, and rotate target segments with skipping free or mostly
> > in-use ones. In that case, nilfs_cleanerd_select_segments() should be
> > modified to select segments in the order of segment number.
> >
> > Cheers,
> > Ryusuke Konishi
> >
> >
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
