Hi, if it is ok for you, I will create a second patch to add the following mount options: minfree, maxfree (or do you prefer other names ?). So different values can be specified for different mount points. What do you think ? Thanks, Arendt David > 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, admin@xxxxxxxxx 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 majordomo@xxxxxxxxxxxxxxx >> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
