mirror of
https://gitee.com/openharmony/third_party_f2fs-tools
synced 2024-11-23 01:59:54 +00:00
resize.f2fs: fix wrong ovp calculation
commitf056fbeff0
category: bugfix issue: #I6VAS0 CVE: NA Signed-off-by: DongSenhao <dongsenhao2@huawei.com> --------------------------------------- beroal reported a mount failure due to broken valid_user_blocks. [ 6890.647749] F2FS-fs (loop0): Wrong valid_user_blocks: 16040048, user_block_count: 10016768 From fsck, segment_count_main [0x 9a95 : 39573] -> 39573 * 2MB = 78GB as user space overprov_segment_count [0x 4e29 : 20009] -> 20009 * 2MB = 40GB as overprovisioned space which user can't see. But, [FSCK] valid_block_count matching with CP [Ok..] [0xf4c070] -> 0xf4c070 = 16040048 valid_block_count [0x f4c070 : 16040048] -> So, this is correct. It turns out resize.f2fs gave very large and wrong overprovisioning space result in shortage of user blocks. The root cause was f2fs_get_usable_segments() didn't consider resize case which needs segment_count_main from new superblock. Fixes:f8410857b7
("f2fs-tools: zns zone-capacity support") Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by: dongsenhao <dongsenhao2@huawei.com>
This commit is contained in:
parent
ea01d23fa6
commit
7774d00ba2
@ -497,6 +497,9 @@ uint32_t f2fs_get_usable_segments(struct f2fs_super_block *sb)
|
||||
int i, j;
|
||||
uint32_t usable_segs = 0, zone_segs;
|
||||
|
||||
if (c.func == RESIZE)
|
||||
return get_sb(segment_count_main);
|
||||
|
||||
for (i = 0; i < c.ndevs; i++) {
|
||||
if (c.devices[i].zoned_model != F2FS_ZONED_HM) {
|
||||
usable_segs += c.devices[i].total_segments;
|
||||
|
Loading…
Reference in New Issue
Block a user