On 2014-01-24 19:26, Ryusuke Konishi wrote:
>> + freeblocks = (nilfs_get_blocks_per_segment(nilfs) * n)
>> + - (nilfs_vector_get_size(vdescv)
>> + + nilfs_vector_get_size(bdescv));
>> +
>> + /* if there are less free blocks than the
>> + * minimal threshold try to update suinfo
>> + * instead of cleaning */
>> + if (freeblocks < minblocks * n) {
>> + ret = gettimeofday(&tv, NULL);
>> + if (ret < 0)
>> + goto out_lock;
>> +
>> + supv = malloc(sizeof(struct nilfs_suinfo_update) * n);
>> + if (supv == NULL) {
>> + ret = -1;
>> + goto out_lock;
>> + }
>> +
>> + for (i = 0; i < n; ++i) {
>> + supv[i].sup_segnum = segnums[i];
>> + supv[i].sup_flags = 0;
>> + nilfs_suinfo_update_set_lastmod(&supv[i]);
>> + supv[i].sup_sui.sui_lastmod = tv.tv_sec;
>> + }
>> +
>> + ret = nilfs_set_suinfo(nilfs, supv, n);
>> + free(supv);
>> + if (ret >= 0) {
>> + /* success, tell caller
>> + * to try another segment/s */
>> + ret = -EGCTRYAGAIN;
>> + goto out_lock;
>> + }
>
> You should design the new reclaim function so that it turns off the
> logic using nilfs_set_suinfo() once nilfs_set_suinfo() returned a
> status code < 0 and errno was ENOTTY.
>
> This fallback logic is needed to keep compatibility for old kernel.
Thanks for your review. I am quite devastated how much needs to be fixed
:). I implemented most of your suggestions. I will test them tomorrow
and compose a new version of the patch set.
> In addition, whether applying the optimization or not, should be
> selectable in /etc/nilfs_cleanerd.conf.
You can set the two options to 0, which would completely disable the
optimization.
# Minimum number of free blocks before a segment
# can be cleaned. Set to 0 to disable it.
min_free_blocks_threshold 0
# Minimum number of free blocks before a segment
# can be cleaned. Set to 0 to disable it.
# if clean segments < min_clean_segments
mc_min_free_blocks_threshold 0
Is that enough or should I add an additional switch, like the use_mmap
switch?
br,
Andreas Rohner
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html