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. > 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? br, Andreas Rohner -- 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
