On Mon, 27 Jan 2014 16:47:32 +0100, Andreas Rohner wrote: > On 2014-01-27 16:03, Ryusuke Konishi wrote: >> Hi Andreas, >> On Mon, 27 Jan 2014 10:58:52 +0100, Andreas Rohner wrote: >>> Hi, >>> >>> This is the third version of this patch set. It basically fixes a >>> lot of bugs. >>> >>> v2->v3 >>> * Alignment in nilfs_suinfo_update >>> * Add missing comments >>> * nilfs2: Extra validity checks in nilfs_sufile_set_suinfo >>> * nilfs2: Update sh_ncleansegs, sh_ndirtysegs if flags change >>> * nilfs2: Fix bugs in nilfs_sufile_set_suinfo >>> * nilfs2: Use vmalloc instead of ioctl_wrap_copy >>> * nilfs-utils: Separate nilfs_relaim_segments_with_threshold >>> * nilfs-utils: Allow different units for min_reclaimable_blocks >>> * nilfs-utils: Introduce flag to disable the optimization >>> * nilfs-utils: Disable optimization if kernel retruns ENOTTY >>> * nilfs-utils: Remove EGCTRYAGAIN error return code >>> * nilfs-utils: Rename option to min_reclaimable_blocks >>> v1->v2 >>> * Implementation of NILFS_IOCTL_SET_SUINFO >>> * Added mc_min_free_blocks_threshold config option >>> (if clean segments < min_clean_segments) >>> * Added new command line param for nilfs-clean >>> * Update man- and config-file >>> >>> This patch set adds an optimized version of >>> nilfs_reclaim_segments, which has an additional parameter >>> min_reclaimable. This parameter specifies the minimum number of >>> reclaimable blocks in a segment, before it can be cleaned. If a >>> segment is below this threshold, it is considered to be not worth >>> cleaning, because all the live blocks would need to be moved to a >>> new segment, which is expensive, and the number of reclaimable >>> blocks is too low. But it is still necessary to update the segment >>> usage information to turn the old segment into a new one. >>> >>> This is basically a shortcut to cleaning the segment. It is still >>> necessary to read the segment summary information, but the writing >>> of the live blocks can be skipped if it's not worth it. >>> >>> Additionally new options are introduced for the configuration file >>> and nilfs-clean to allow the user to specify the threshold. >>> >>> This is potentially useful for all gc policies, but it is especially >>> beneficial for the timestamp policy. Lets assume for example a NILFS2 >>> volume with 20% static files and lets assume these static files >>> are in the oldest segments. The current timestamp policy will >>> select the oldest segments and, since the data is static, move >>> them mostly unchanged to new segments. After a while they will >>> become the oldest segments again. Then timestamp will move them >>> again. These moving operations are expensive and unnecessary. >>> >>> The benchmarks are currently running. I will give you the results >>> shortly. >> >> The kernel patchset didn't apply to the mainline as is because >> Vyacheslav's ioctl commentary patch just has been merged. Please >> rebase your patchset on the current master branch next time. Also, >> nilfs_ioctl_set_suinfo() function needs summary comment as for the >> current master branch. > > Sorry for that, I based it on 3.13. I will rebase it immediateley and > add the summary comment. I already rebased it manually. Please wait until I complete the review for all patches. >> Anyway, I will review the kernel patches first, and then look into >> the userland patches. > > Thanks. By the way, is it ok to use one cover letter for both the > userland and kernel patches? No problem. In either case, I will add a cover letter when I send them to upstream. 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
