On 2022/10/1 6:33, Jaegeuk Kim wrote:
On 09/30, Chao Yu wrote:
On 2022/9/30 2:27, Jaegeuk Kim wrote:
On 09/28, Chao Yu wrote:
On 2022/9/28 11:15, Jaegeuk Kim wrote:
On 09/28, Chao Yu wrote:
On 2022/9/28 0:40, Jaegeuk Kim wrote:
On 09/25, Chao Yu wrote:
Update allocation policy for ro feature:
- hot_data: allocating blocks by LBA ascending order
- hot_node: allocating blocks by LBA descending order
This will increase the RO image size.
Shouldn't RO image has fixed-size during mkfs?
First run gives the reduced size information, and second round makes the image
with the required size.
I didn't get it, in which step it may increase the RO image size?
IIUC, after we apply this patch, reduced size information won't change due
to that after sload in first run, total used block count should be fixed?
First run fills the data and leaves the maximum LBA touched in the image. Then,
How about caclulating required size w/ total used blocks rather than maximum
LBA?
Do you think that can give the smallest size for the image?
I guess so, but let me do some tests to check that.
Segments for data block and node block should be calculated separately:
required_blks = roundup(data_blks, blks_per_seg) + roundup(node_blks,
blks_per_seg)
Am I missing something?
Thanks,
Thanks,
it'll resize the image file and run again with the smallest image.
Thanks,
Signed-off-by: Chao Yu <[email protected]>
---
mkfs/f2fs_format.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mkfs/f2fs_format.c b/mkfs/f2fs_format.c
index 40ac589..8d0f410 100644
--- a/mkfs/f2fs_format.c
+++ b/mkfs/f2fs_format.c
@@ -544,10 +544,10 @@ static int f2fs_prepare_super_block(void)
}
if (c.feature & cpu_to_le32(F2FS_FEATURE_RO)) {
- c.cur_seg[CURSEG_HOT_NODE] = 0;
+ c.cur_seg[CURSEG_HOT_NODE] =
last_section(last_zone(total_zones));
c.cur_seg[CURSEG_WARM_NODE] = 0;
c.cur_seg[CURSEG_COLD_NODE] = 0;
- c.cur_seg[CURSEG_HOT_DATA] = 1;
+ c.cur_seg[CURSEG_HOT_DATA] = 0;
c.cur_seg[CURSEG_COLD_DATA] = 0;
c.cur_seg[CURSEG_WARM_DATA] = 0;
} else if (c.heap) {
--
2.36.1
_______________________________________________
Linux-f2fs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
