Make.f2fs supports manually specifying overprovision, and we expect
resize.f2fs to support it as well.
This change add a new '-o' option to manually specify overprovision,
and fix to check free space before grow. Otherwise, after grow,
kernel may report below error message when we mount the image if -o
parameter is specified during resize:
F2FS-fs (loop0): invalid crc_offset: 0
F2FS-fs (loop0): Wrong valid_user_blocks: 16404, user_block_count: 13312
F2FS-fs (loop0): Failed to get valid F2FS checkpoint
mount(2) system call failed: Structure needs cleaning.
Signed-off-by: liuchao12 <liuchao12@xiaomi.com>
Signed-off-by: qixiaoyu1 <qixiaoyu1@xiaomi.com>
Reviewed-by: Chao Yu <chao@kernel.org>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Change-Id: I2ad0ecc5546a1712b7aa36230e91c3e0b1beb7e0
commit 87d7a95e3134b668e9f1e8519a19f390509fac60
category: bugfix
issue: #I6VAS0
CVE: NA
Signed-off-by: DongSenhao <dongsenhao2@huawei.com>
---------------------------------------
Many format strings use one of the PRI* macros. These macros are compatible
with the uint types but not with the u_int types. Hence this patch
that switches from the u_int to the uint types.
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: dongsenhao <dongsenhao2@huawei.com>
resize.f2fs has already supported large_nat_bitmap feature, but has no
option to turn on it.
This change add a new '-i' option to control turning on it.
Signed-off-by: xiongping1 <xiongping1@xiaomi.com>
Reviewed-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
For large_nat_bitmap feature, there is a design flaw:
Previous:
struct f2fs_checkpoint layout:
+--------------------------+ 0x0000
| checkpoint_ver |
| ...... |
| checksum_offset |------+
| ...... | |
| sit_nat_version_bitmap[] |<-----|-------+
| ...... | | |
| checksum_value |<-----+ |
+--------------------------+ 0x1000 |
| | nat_bitmap + sit_bitmap
| payload blocks | |
| | |
+--------------------------|<-------------+
Obviously, if nat_bitmap size + sit_bitmap size is larger than
MAX_BITMAP_SIZE_IN_CKPT, nat_bitmap or sit_bitmap may overlap
checkpoint checksum's position, once checkpoint() is triggered
from kernel, nat or sit bitmap will be damaged by checksum field.
In order to fix this, let's relocate checksum_value's position
to the head of sit_nat_version_bitmap as below, then nat/sit
bitmap and chksum value update will become safe.
After:
struct f2fs_checkpoint layout:
+--------------------------+ 0x0000
| checkpoint_ver |
| ...... |
| checksum_offset |------+
| ...... | |
| sit_nat_version_bitmap[] |<-----+
| ...... |<-------------+
| | |
+--------------------------+ 0x1000 |
| | nat_bitmap + sit_bitmap
| payload blocks | |
| | |
+--------------------------|<-------------+
Related report and discussion:
https://sourceforge.net/p/linux-f2fs/mailman/message/36642346/
In addition, during writing checkpoint, if large_nat_bitmap feature is
enabled, we need to set CP_LARGE_NAT_BITMAP_FLAG flag in checkpoint.
Reported-by: Park Ju Hyung <qkrwngud825@gmail.com>
Signed-off-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Previously, f2fs_checkpoint.checksum_offset points fixed position of
f2fs_checkpoint structure:
"#define CP_CHKSUM_OFFSET 4092"
It is unnecessary, and it breaks the consecutiveness of nat and sit
bitmap stored across checkpoint park block and payload blocks.
This patch allows f2fs-tools to handle unfixed .checksum_offset.
In addition, for the case checksum value is stored in the middle of
checkpoint park, calculating checksum value with superposition method
like we did for inode_checksum.
In addition, add below change:
- using MAX_BITMAP_SIZE_IN_CKPT to clean up codes.
- introduce verify_checksum_chksum() to verify chksum_{offset,value}
Signed-off-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Rename write_superblock() to update_superblock() and make it support updating
specified one superblock or both two superblocks, then unify all places where
sb needs to be updated.
Signed-off-by: Junling Zheng <zhengjunling@huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
allow 'safe' resizing leaving the metadata nearly unchanged.
Will likely need to adjust growing for the case where a fs
had previously shrunk without altering data, and the newly grown
fs would be smaller than the original. Probably makes sense to
case it out into metadata size changes, instead of fs size changes
Signed-off-by: Daniel Rosenberg <drosen@google.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>
zone_align_start_offset should be u64, but config.start_sector is u32,
so it may be overflow when computing zone_align_start_offset.
Signed-off-by: Yunlong Song <yunlong.song@huawei.com>
Reviewed-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
f2fs-tools uses ioctl BLKSSZGET to get sector_size, however, this ioctl
will return a value which may be larger than 512 (according to the value
of q->limits.logical_block_size), then this will be inconsistent with
the start_sector, since start_sector is got from ioctl HDIO_GETGEO and
is always in 512 size unit for a sector. To fix this problem, just
change the sector_size to the default value when computing with
start_sector. And fix sectors_per_blk as well.
Signed-off-by: Yunlong Song <yunlong.song@huawei.com>
Reviewed-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
This patch add -O features for fsck.f2fs in order to tune the feature bits.
Currently, it supports -O encrypt only.
Reviewed-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Resize rebuilds checkpoint with 6 summary blocks, so if
CP_COMPACT_SUM_FLAG is set in the old checkpoint, clear it.
Signed-off-by: Sheng Yong <shengyong1@huawei.com>
Reviewed-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
When wring the last nat_bits in new checkpoint, we call write_nat_bits()
to recover the nat_bits. But, we didn't update nm_i->nat_bitmap which we can
get the up-to-date nat blocks. After sit migration, old checkpoint has no
longer valid nat blocks, resulting in wrong free nid allocation at the following
mount time.
Let's indicate new nat_blocks by adjusting nat_bitmap in nat migration.
Reported-by: Lianjun Huang <huanglianjun@vivo.com>
Reviewed-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
For the same reason as "mkfs.f2fs: fix to calculate
left space of checkpoint page correctly",
this patch also fixes miscalculatation in resize.f2fs.
Signed-off-by: Gao Xiang <gaoxiang25@huawei.com>
Reviewed-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
resize.f2fs rebuilds a new checkpoint at the new position. Its
checkpoint_ver should be increased.
Signed-off-by: Shuoran Liu <liushuoran@huawei.com>
Signed-off-by: Weichao Guo <guoweichao@huawei.com>
Signed-off-by: Sheng Yong <shengyong1@huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
This patch remove unused parameters in these three functions:
get_new_sb, migrate_main and rebuild_superblock
Signed-off-by: Yunlei He <heyunlei@huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
If the offset passed in migrate_ssa is not zero, it means that there're
offset segments of old main will disappear after migrating, then there're
offset blocks of old ssa should be invalidated and removed accordingly.
So, the number of moved ssa blocks should be: TOTAL_SEGS(sbi) - offset,
and the expanded summary, which is filled with zero_blocks, should start
from: new_sum_blkaddr + TOTAL_SEGS(sbi) - offset.
Signed-off-by: Yunlei He <heyunlei@huawei.com>
Signed-off-by: Junling Zheng <zhengjunling@huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
When we move whole main area into new expanded area, we do not change its
segment numbers from sit and ssa.
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
This patch replace the overprovision calculation method from
mkfs tool.
Signed-off-by: Yunlei He <heyunlei@huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Now user can expand existing partition with resize.f2fs.
Currently, it doesn't support shrink an image.
For example,
# resize.f2fs -t [# of sectors] [image]
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
