During mkfs, segment_count_sit is calculated using ALIGN and
SEG_ALIGN, which are both upward. Then, in some extreme scenarios,
such as 16TB, sit_ver_bitmap_bytesize got from segment_count_sit
will exceed MAX_SIT_BITMAP_SIZE, which is calculated in a downward
method.
Unify the two calculating methods and redefine MAX_SIT_BITMAP_SIZE
to prevent sit_ver_bitmap_bytesize overflowing.
Signed-off-by: Junling Zheng <zhengjunl...@huawei.com>
---
include/f2fs_fs.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/f2fs_fs.h b/include/f2fs_fs.h
index b58aa74..3a1d2d1 100644
--- a/include/f2fs_fs.h
+++ b/include/f2fs_fs.h
@@ -642,7 +642,9 @@ struct f2fs_nat_block {
* disk is 16 TB and it equals to 16 * 1024 * 1024 / 2 segments.
*/
#define F2FS_MAX_SEGMENT ((16 * 1024 * 1024) / 2)
-#define MAX_SIT_BITMAP_SIZE ((F2FS_MAX_SEGMENT / SIT_ENTRY_PER_BLOCK) / 8)
+#define MAX_SIT_BITMAP_SIZE (SEG_ALIGN(ALIGN(F2FS_MAX_SEGMENT, \
+ SIT_ENTRY_PER_BLOCK)) * \
+ config.blks_per_seg / 8)
/*
* Note that f2fs_sit_entry->vblocks has the following bit-field information.
--
1.9.1
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
