On Sun, 31 May 2015 20:13:44 +0200, Andreas Rohner wrote: > On 2015-05-31 18:45, Ryusuke Konishi wrote: >> On Fri, 22 May 2015 20:10:05 +0200, Andreas Rohner wrote: >>> On 2015-05-20 16:43, Ryusuke Konishi wrote: >>>> On Sun, 3 May 2015 12:05:22 +0200, Andreas Rohner wrote: [...] >>>> 3. The ratio of the threshold "max_segblks" is hard coded to 50% >>>> of blocks_per_segment. It is not clear if the ratio is good >>>> (versatile). >>> >>> The interval and percentage could be set in /etc/nilfs_cleanerd.conf. >>> >>> I chose 50% kind of arbitrarily. My intent was to encourage the GC to >>> check the segment again in the future. I guess anything between 25% and >>> 75% would also work. >> >> Sound reasonable. >> >> By the way, I am thinking we should move cleanerd into kernel as soon >> as we can. It's not only inefficient due to a large amount of data >> exchange between kernel and user-land, but also is hindering changes >> like we are trying. We have to care compatibility unnecessarily due >> to the early design mistake (i.e. the separation of gc to user-land). > > I am a bit confused. Is it OK if I implement this functionality in > nilfs_cleanerd for this patch set, or would it be better to implement it > with a workqueue in the kernel, like you've suggested before? > > If you intend to move nilfs_cleanerd into the kernel anyway, then the > latter would make more sense to me. Which implementation do you prefer > for this patch set? If nilfs_cleanerd will remain in userland, then the userland implementation looks better. But, yes, if we will move the cleaner into kernel, then the kernel implementation looks better because we may be able to avoid unnecessary API change. It's a dilemma. Do you have any good idea to reduce or hide overhead of the calibration (i.e. traversal rewrite of sufile) in regard to the kernel implementation ? I'm inclined to leave that in kernel for now. Regards, Ryusuke Konishi > > Regards, > Andreas Rohner > >> Regards, >> 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 -- 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
