summaryrefslogtreecommitdiffstats
path: root/fs/fuse
diff options
context:
space:
mode:
authorChao Yu <yuchao0@huawei.com>2017-10-18 10:34:14 +0800
committerJaegeuk Kim <jaegeuk@kernel.org>2017-10-26 10:44:24 +0200
commit7e515b31d44dcd20a98c938dfdc21877a30042a0 (patch)
treea4de06d3ec34b1ff3678d77f893a4422ecb8607e /fs/fuse
parent6e5b5d41c93ef79e9f297f9a3b40730bf0b41f31 (diff)
downloadlinux-stable-7e515b31d44dcd20a98c938dfdc21877a30042a0.tar.gz
linux-stable-7e515b31d44dcd20a98c938dfdc21877a30042a0.tar.bz2
linux-stable-7e515b31d44dcd20a98c938dfdc21877a30042a0.zip
f2fs: fix to correct no_fggc_candidate
There may be extreme case as below: For one section contains one segment, and there are total 100 segments with 10% over-privision ratio in f2fs partition, fggc_threshold will be rounded down to 460 instead of 460.8 as below caclulation: sbi->fggc_threshold = div_u64((u64)(main_count - ovp_count) * BLKS_PER_SEC(sbi), (main_count - resv_count)); If section usage is as: 60 segments which contain 460 valid blocks 40 segments which contain 462 valid blocks As valid block number in all sections is large than fggc_threshold, so none of them will be chosen as candidate due to incorrect fggc_threshold. Let's just soften the term of choosing foreground GC candidates. Signed-off-by: Chao Yu <yuchao0@huawei.com> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Diffstat (limited to 'fs/fuse')
0 files changed, 0 insertions, 0 deletions