* [PATCH] ext4: Regression test of ext4_lblk_t overflow
@ 2023-10-28 7:01 Baokun Li
2023-11-17 14:24 ` Zorro Lang
0 siblings, 1 reply; 5+ messages in thread
From: Baokun Li @ 2023-10-28 7:01 UTC (permalink / raw)
To: fstests; +Cc: zlang, guaneryu, amir73il, ritesh.list, yangerkun, libaokun1
Append writes to a file approaching 16T and observe if a kernel crash is
caused by ext4_lblk_t overflow triggering BUG_ON at ext4_mb_new_inode_pa().
This is a regression test for commit bc056e7163ac ("ext4: fix BUG in
ext4_mb_new_inode_pa() due to overflow")
Signed-off-by: Baokun Li <libaokun1@huawei.com>
---
tests/ext4/062 | 53 ++++++++++++++++++++++++++++++++++++++++++++++
tests/ext4/062.out | 2 ++
2 files changed, 55 insertions(+)
create mode 100755 tests/ext4/062
create mode 100644 tests/ext4/062.out
diff --git a/tests/ext4/062 b/tests/ext4/062
new file mode 100755
index 00000000..0ae4ed80
--- /dev/null
+++ b/tests/ext4/062
@@ -0,0 +1,53 @@
+#! /bin/bash
+# SPDX-License-Identifier: GPL-2.0
+# Copyright (c) 2023 HUAWEI. All Rights Reserved.
+#
+# FS QA Test No. 062
+#
+# Append writes to a file approaching 16T and observe if a kernel crash is
+# caused by ext4_lblk_t overflow triggering BUG_ON at ext4_mb_new_inode_pa().
+# This is a regression test for commit
+# bc056e7163ac ("ext4: fix BUG in ext4_mb_new_inode_pa() due to overflow")
+#
+. ./common/preamble
+_begin_fstest auto quick insert
+
+# real QA test starts here
+_supported_fs ext4
+_fixed_by_kernel_commit bc056e7163ac \
+ "ext4: fix BUG in ext4_mb_new_inode_pa() due to overflow"
+
+_require_xfs_io_command "falloc"
+_require_xfs_io_command "open"
+_require_xfs_io_command "pwrite"
+_require_scratch_size_nocheck $((100 * 1024)) # 100MB in KB
+
+# Initalize a 4k 100M ext4 fs
+dev_size=$((100 * 1024 * 1024))
+MKFS_OPTIONS="-b 4096 $MKFS_OPTIONS" _scratch_mkfs_sized $dev_size \
+ >>$seqres.full 2>&1 || _fail "mkfs failed"
+
+_scratch_mount
+
+# Reserve 1M space
+$XFS_IO_PROG -f -c "falloc 0 1M" "${SCRATCH_MNT}/tmp" >> $seqres.full 2>&1
+
+# Create a file with logical block numbers close to overflow
+$XFS_IO_PROG -f -c "falloc 0 10M" "${SCRATCH_MNT}/file" >> $seqres.full 2>&1
+$XFS_IO_PROG -f -c "finsert 1M 16777203M" "${SCRATCH_MNT}/file" >> $seqres.full 2>&1
+
+# Filling up the free space ensures that the pre-allocated space is the reserved space.
+$XFS_IO_PROG -f -c "falloc 0 80388096" "${SCRATCH_MNT}/fill" >> $seqres.full 2>&1
+
+# Remove reserved space to gain free space for allocation
+rm -f ${SCRATCH_MNT}/tmp
+
+# Trying to allocate two blocks triggers BUG_ON.
+$XFS_IO_PROG -c "open -ad ${SCRATCH_MNT}/file" -c "pwrite -S 0xff 0 8192" >> $seqres.full 2>&1
+
+umount "${SCRATCH_MNT}"
+echo "Silence is golden"
+
+# success, all done
+status=0
+exit
diff --git a/tests/ext4/062.out b/tests/ext4/062.out
new file mode 100644
index 00000000..a1578f48
--- /dev/null
+++ b/tests/ext4/062.out
@@ -0,0 +1,2 @@
+QA output created by 062
+Silence is golden
--
2.31.1
^ permalink raw reply related [flat|nested] 5+ messages in thread* Re: [PATCH] ext4: Regression test of ext4_lblk_t overflow 2023-10-28 7:01 [PATCH] ext4: Regression test of ext4_lblk_t overflow Baokun Li @ 2023-11-17 14:24 ` Zorro Lang 2023-11-18 3:08 ` Baokun Li 0 siblings, 1 reply; 5+ messages in thread From: Zorro Lang @ 2023-11-17 14:24 UTC (permalink / raw) To: Baokun Li; +Cc: fstests, guaneryu, amir73il, ritesh.list, yangerkun On Sat, Oct 28, 2023 at 03:01:23PM +0800, Baokun Li wrote: > Append writes to a file approaching 16T and observe if a kernel crash is > caused by ext4_lblk_t overflow triggering BUG_ON at ext4_mb_new_inode_pa(). > This is a regression test for commit bc056e7163ac ("ext4: fix BUG in > ext4_mb_new_inode_pa() due to overflow") > > Signed-off-by: Baokun Li <libaokun1@huawei.com> > --- Hi Baokun, Thanks for this new coverage, some review points as below ... > tests/ext4/062 | 53 ++++++++++++++++++++++++++++++++++++++++++++++ > tests/ext4/062.out | 2 ++ > 2 files changed, 55 insertions(+) > create mode 100755 tests/ext4/062 > create mode 100644 tests/ext4/062.out > > diff --git a/tests/ext4/062 b/tests/ext4/062 > new file mode 100755 > index 00000000..0ae4ed80 > --- /dev/null > +++ b/tests/ext4/062 > @@ -0,0 +1,53 @@ > +#! /bin/bash > +# SPDX-License-Identifier: GPL-2.0 > +# Copyright (c) 2023 HUAWEI. All Rights Reserved. > +# > +# FS QA Test No. 062 > +# > +# Append writes to a file approaching 16T and observe if a kernel crash is > +# caused by ext4_lblk_t overflow triggering BUG_ON at ext4_mb_new_inode_pa(). > +# This is a regression test for commit > +# bc056e7163ac ("ext4: fix BUG in ext4_mb_new_inode_pa() due to overflow") > +# > +. ./common/preamble > +_begin_fstest auto quick insert ^^^ prealloc > + > +# real QA test starts here > +_supported_fs ext4 > +_fixed_by_kernel_commit bc056e7163ac \ > + "ext4: fix BUG in ext4_mb_new_inode_pa() due to overflow" > + > +_require_xfs_io_command "falloc" > +_require_xfs_io_command "open" > +_require_xfs_io_command "pwrite" I think we don't need to check the "open" and "pwrite" operations, if you don't need special option for them. > +_require_scratch_size_nocheck $((100 * 1024)) # 100MB in KB I think 100MB is small enough, don't need this check. > + > +# Initalize a 4k 100M ext4 fs > +dev_size=$((100 * 1024 * 1024)) > +MKFS_OPTIONS="-b 4096 $MKFS_OPTIONS" _scratch_mkfs_sized $dev_size \ > + >>$seqres.full 2>&1 || _fail "mkfs failed" Can we use bsize=$(_get_file_block_size ....) to get the real block size, to avoid use a specific mkfs option? If so, my second question is if this case can be a generic case. The test steps look common enough, I'm glad to see what will happen on other filesystems through this test. > + > +_scratch_mount > + > +# Reserve 1M space > +$XFS_IO_PROG -f -c "falloc 0 1M" "${SCRATCH_MNT}/tmp" >> $seqres.full 2>&1 > + > +# Create a file with logical block numbers close to overflow > +$XFS_IO_PROG -f -c "falloc 0 10M" "${SCRATCH_MNT}/file" >> $seqres.full 2>&1 > +$XFS_IO_PROG -f -c "finsert 1M 16777203M" "${SCRATCH_MNT}/file" >> $seqres.full 2>&1 _require_xfs_io_command "finsert" > + > +# Filling up the free space ensures that the pre-allocated space is the reserved space. > +$XFS_IO_PROG -f -c "falloc 0 80388096" "${SCRATCH_MNT}/fill" >> $seqres.full 2>&1 Can we make sure this step fill the whole free space? There's a helper in common/populate named _fill_fs, please check if it's what you want? > + > +# Remove reserved space to gain free space for allocation > +rm -f ${SCRATCH_MNT}/tmp > + > +# Trying to allocate two blocks triggers BUG_ON. > +$XFS_IO_PROG -c "open -ad ${SCRATCH_MNT}/file" -c "pwrite -S 0xff 0 8192" >> $seqres.full 2>&1 Oh, you need open -d option, that means you need direct IO, so you need: _require_odirect And all above xfs_io commands, include falloc, finsert, open and pwrite. You can redirect the stdout to $seqres.full, but better *not* to change the stderr, for we can find errors if they fail (except that expected ENOSPC). > + > +umount "${SCRATCH_MNT}" The $SCRATCH_MNT will be unmounted at the end of the testing, don't need to do it manually, except this's a necessary step of the reproducer. > +echo "Silence is golden" > + > +# success, all done > +status=0 > +exit > diff --git a/tests/ext4/062.out b/tests/ext4/062.out > new file mode 100644 > index 00000000..a1578f48 > --- /dev/null > +++ b/tests/ext4/062.out > @@ -0,0 +1,2 @@ > +QA output created by 062 > +Silence is golden > -- > 2.31.1 > > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] ext4: Regression test of ext4_lblk_t overflow 2023-11-17 14:24 ` Zorro Lang @ 2023-11-18 3:08 ` Baokun Li 2023-11-19 13:14 ` Zorro Lang 0 siblings, 1 reply; 5+ messages in thread From: Baokun Li @ 2023-11-18 3:08 UTC (permalink / raw) To: Zorro Lang; +Cc: fstests, guaneryu, amir73il, ritesh.list, yangerkun, Baokun Li On 2023/11/17 22:24, Zorro Lang wrote: > Hi Baokun, > > Thanks for this new coverage, some review points as below ... > Hi Zorro, Thank you for your careful review! >> tests/ext4/062 | 53 ++++++++++++++++++++++++++++++++++++++++++++++ >> tests/ext4/062.out | 2 ++ >> 2 files changed, 55 insertions(+) >> create mode 100755 tests/ext4/062 >> create mode 100644 tests/ext4/062.out >> >> diff --git a/tests/ext4/062 b/tests/ext4/062 >> new file mode 100755 >> index 00000000..0ae4ed80 >> --- /dev/null >> +++ b/tests/ext4/062 >> @@ -0,0 +1,53 @@ >> +#! /bin/bash >> +# SPDX-License-Identifier: GPL-2.0 >> +# Copyright (c) 2023 HUAWEI. All Rights Reserved. >> +# >> +# FS QA Test No. 062 >> +# >> +# Append writes to a file approaching 16T and observe if a kernel crash is >> +# caused by ext4_lblk_t overflow triggering BUG_ON at ext4_mb_new_inode_pa(). >> +# This is a regression test for commit >> +# bc056e7163ac ("ext4: fix BUG in ext4_mb_new_inode_pa() due to overflow") >> +# >> +. ./common/preamble >> +_begin_fstest auto quick insert > ^^^ > prealloc I'll add this. >> + >> +# real QA test starts here >> +_supported_fs ext4 >> +_fixed_by_kernel_commit bc056e7163ac \ >> + "ext4: fix BUG in ext4_mb_new_inode_pa() due to overflow" >> + >> +_require_xfs_io_command "falloc" >> +_require_xfs_io_command "open" >> +_require_xfs_io_command "pwrite" > I think we don't need to check the "open" and "pwrite" operations, > if you don't need special option for them. OK! >> +_require_scratch_size_nocheck $((100 * 1024)) # 100MB in KB > I think 100MB is small enough, don't need this check. All right! >> + >> +# Initalize a 4k 100M ext4 fs >> +dev_size=$((100 * 1024 * 1024)) >> +MKFS_OPTIONS="-b 4096 $MKFS_OPTIONS" _scratch_mkfs_sized $dev_size \ >> + >>$seqres.full 2>&1 || _fail "mkfs failed" > Can we use bsize=$(_get_file_block_size ....) to get the real block size, > to avoid use a specific mkfs option? > If so, my second question is if this case can be a generic case. The test > steps look common enough, I'm glad to see what will happen on other > filesystems through this test. The reason for specifying 4096 for formatting here is that mkfs.ext4 specifies a default block size of 1024 when the disk image is 100M. Although these operations appear to be generic scenarios, the reproduction of this problem relies on ext4's pre-allocation mechanism. Block allocation requests are scaled up in ext4_mb_normalize_request(), and the extra blocks are used for preallocation to reduce fragmentation. Therefore, this test case is placed only in the ext4 test suite. > >> + >> +_scratch_mount >> + >> +# Reserve 1M space >> +$XFS_IO_PROG -f -c "falloc 0 1M" "${SCRATCH_MNT}/tmp" >> $seqres.full 2>&1 >> + >> +# Create a file with logical block numbers close to overflow >> +$XFS_IO_PROG -f -c "falloc 0 10M" "${SCRATCH_MNT}/file" >> $seqres.full 2>&1 >> +$XFS_IO_PROG -f -c "finsert 1M 16777203M" "${SCRATCH_MNT}/file" >> $seqres.full 2>&1 > _require_xfs_io_command "finsert" Okay. > >> + >> +# Filling up the free space ensures that the pre-allocated space is the reserved space. >> +$XFS_IO_PROG -f -c "falloc 0 80388096" "${SCRATCH_MNT}/fill" >> $seqres.full 2>&1 > Can we make sure this step fill the whole free space? There's a helper in > common/populate named _fill_fs, please check if it's what you want? The remaining space for a 100M 4k ext4 image after the previous operations is 80388096, so we can confirm that we can fill the entire free space here. Of course, using _fill_fs is also workable, but it's faster to do it in a single fallocate. >> + >> +# Remove reserved space to gain free space for allocation >> +rm -f ${SCRATCH_MNT}/tmp >> + >> +# Trying to allocate two blocks triggers BUG_ON. >> +$XFS_IO_PROG -c "open -ad ${SCRATCH_MNT}/file" -c "pwrite -S 0xff 0 8192" >> $seqres.full 2>&1 > Oh, you need open -d option, that means you need direct IO, so you need: > _require_odirect Indeed! > And all above xfs_io commands, include falloc, finsert, open and pwrite. > You can redirect the stdout to $seqres.full, but better *not* to change > the stderr, for we can find errors if they fail (except that expected ENOSPC). Ok, I'll remove the unnecessary "2>&1"! >> + >> +umount "${SCRATCH_MNT}" > The $SCRATCH_MNT will be unmounted at the end of the testing, don't need to do > it manually, except this's a necessary step of the reproducer. Okay, I will remove it. > >> +echo "Silence is golden" >> + >> +# success, all done >> +status=0 >> +exit >> diff --git a/tests/ext4/062.out b/tests/ext4/062.out >> new file mode 100644 >> index 00000000..a1578f48 >> --- /dev/null >> +++ b/tests/ext4/062.out >> @@ -0,0 +1,2 @@ >> +QA output created by 062 >> +Silence is golden >> -- >> 2.31.1 >> >> > Thanks! -- With Best Regards, Baokun Li . ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] ext4: Regression test of ext4_lblk_t overflow 2023-11-18 3:08 ` Baokun Li @ 2023-11-19 13:14 ` Zorro Lang 2023-11-20 3:44 ` Baokun Li 0 siblings, 1 reply; 5+ messages in thread From: Zorro Lang @ 2023-11-19 13:14 UTC (permalink / raw) To: Baokun Li; +Cc: fstests, guaneryu, amir73il, ritesh.list, yangerkun On Sat, Nov 18, 2023 at 11:08:10AM +0800, Baokun Li wrote: > On 2023/11/17 22:24, Zorro Lang wrote: > > Hi Baokun, > > > > Thanks for this new coverage, some review points as below ... > > > Hi Zorro, > > Thank you for your careful review! > > > > tests/ext4/062 | 53 ++++++++++++++++++++++++++++++++++++++++++++++ > > > tests/ext4/062.out | 2 ++ > > > 2 files changed, 55 insertions(+) > > > create mode 100755 tests/ext4/062 > > > create mode 100644 tests/ext4/062.out > > > > > > diff --git a/tests/ext4/062 b/tests/ext4/062 > > > new file mode 100755 > > > index 00000000..0ae4ed80 > > > --- /dev/null > > > +++ b/tests/ext4/062 > > > @@ -0,0 +1,53 @@ > > > +#! /bin/bash > > > +# SPDX-License-Identifier: GPL-2.0 > > > +# Copyright (c) 2023 HUAWEI. All Rights Reserved. > > > +# > > > +# FS QA Test No. 062 > > > +# > > > +# Append writes to a file approaching 16T and observe if a kernel crash is > > > +# caused by ext4_lblk_t overflow triggering BUG_ON at ext4_mb_new_inode_pa(). > > > +# This is a regression test for commit > > > +# bc056e7163ac ("ext4: fix BUG in ext4_mb_new_inode_pa() due to overflow") > > > +# > > > +. ./common/preamble > > > +_begin_fstest auto quick insert > > ^^^ > > prealloc > I'll add this. > > > + > > > +# real QA test starts here > > > +_supported_fs ext4 > > > +_fixed_by_kernel_commit bc056e7163ac \ > > > + "ext4: fix BUG in ext4_mb_new_inode_pa() due to overflow" > > > + > > > +_require_xfs_io_command "falloc" > > > +_require_xfs_io_command "open" > > > +_require_xfs_io_command "pwrite" > > I think we don't need to check the "open" and "pwrite" operations, > > if you don't need special option for them. > OK! > > > +_require_scratch_size_nocheck $((100 * 1024)) # 100MB in KB > > I think 100MB is small enough, don't need this check. > All right! > > > + > > > +# Initalize a 4k 100M ext4 fs > > > +dev_size=$((100 * 1024 * 1024)) > > > +MKFS_OPTIONS="-b 4096 $MKFS_OPTIONS" _scratch_mkfs_sized $dev_size \ > > > + >>$seqres.full 2>&1 || _fail "mkfs failed" > > Can we use bsize=$(_get_file_block_size ....) to get the real block size, > > to avoid use a specific mkfs option? > > If so, my second question is if this case can be a generic case. The test > > steps look common enough, I'm glad to see what will happen on other > > filesystems through this test. > The reason for specifying 4096 for formatting here is that mkfs.ext4 > specifies a > default block size of 1024 when the disk image is 100M. Is the reproducer related with the block size. If it's not, we can use "bsize=$(_get_file_block_size $SCRATCH_MNT)" to get the block size, and change later 4096 to $bsize. > > Although these operations appear to be generic scenarios, the reproduction > of > this problem relies on ext4's pre-allocation mechanism. Block allocation > requests > are scaled up in ext4_mb_normalize_request(), and the extra blocks are used > for > preallocation to reduce fragmentation. Therefore, this test case is placed > only in > the ext4 test suite. Sure it's a reproducer for ext4, but it can be run for other filesystems which support falloc and finsert. And: _require_xfs_io_command "falloc" _require_xfs_io_command "finsert" will make sure the current FSTYP supports these two features. So it can be a bug coverage for ext4, and a generic test case for other fs. > > > > > + > > > +_scratch_mount > > > + > > > +# Reserve 1M space > > > +$XFS_IO_PROG -f -c "falloc 0 1M" "${SCRATCH_MNT}/tmp" >> $seqres.full 2>&1 > > > + > > > +# Create a file with logical block numbers close to overflow > > > +$XFS_IO_PROG -f -c "falloc 0 10M" "${SCRATCH_MNT}/file" >> $seqres.full 2>&1 > > > +$XFS_IO_PROG -f -c "finsert 1M 16777203M" "${SCRATCH_MNT}/file" >> $seqres.full 2>&1 > > _require_xfs_io_command "finsert" > Okay. > > > > > + > > > +# Filling up the free space ensures that the pre-allocated space is the reserved space. > > > +$XFS_IO_PROG -f -c "falloc 0 80388096" "${SCRATCH_MNT}/fill" >> $seqres.full 2>&1 > > Can we make sure this step fill the whole free space? There's a helper in > > common/populate named _fill_fs, please check if it's what you want? > The remaining space for a 100M 4k ext4 image after the previous operations > is > 80388096, so we can confirm that we can fill the entire free space here. > Of course, using _fill_fs is also workable, but it's faster to do it in a > single fallocate. I'm not sure how the reservation works, if there're 90M free space, and you try to reserve 90+M, will once fallocate calling trys to reserve each free blocks, before returning error? If it's not, I think the _fill_fs might be what you want. Thanks, Zorro > > > + > > > +# Remove reserved space to gain free space for allocation > > > +rm -f ${SCRATCH_MNT}/tmp > > > + > > > +# Trying to allocate two blocks triggers BUG_ON. > > > +$XFS_IO_PROG -c "open -ad ${SCRATCH_MNT}/file" -c "pwrite -S 0xff 0 8192" >> $seqres.full 2>&1 > > Oh, you need open -d option, that means you need direct IO, so you need: > > _require_odirect > > Indeed! > > > And all above xfs_io commands, include falloc, finsert, open and pwrite. > > You can redirect the stdout to $seqres.full, but better *not* to change > > the stderr, for we can find errors if they fail (except that expected ENOSPC). > Ok, I'll remove the unnecessary "2>&1"! > > > + > > > +umount "${SCRATCH_MNT}" > > The $SCRATCH_MNT will be unmounted at the end of the testing, don't need to do > > it manually, except this's a necessary step of the reproducer. > Okay, I will remove it. > > > > > +echo "Silence is golden" > > > + > > > +# success, all done > > > +status=0 > > > +exit > > > diff --git a/tests/ext4/062.out b/tests/ext4/062.out > > > new file mode 100644 > > > index 00000000..a1578f48 > > > --- /dev/null > > > +++ b/tests/ext4/062.out > > > @@ -0,0 +1,2 @@ > > > +QA output created by 062 > > > +Silence is golden > > > -- > > > 2.31.1 > > > > > > > > > Thanks! > -- > With Best Regards, > Baokun Li > . > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] ext4: Regression test of ext4_lblk_t overflow 2023-11-19 13:14 ` Zorro Lang @ 2023-11-20 3:44 ` Baokun Li 0 siblings, 0 replies; 5+ messages in thread From: Baokun Li @ 2023-11-20 3:44 UTC (permalink / raw) To: Zorro Lang; +Cc: fstests, guaneryu, amir73il, ritesh.list, yangerkun, Baokun Li On 2023/11/19 21:14, Zorro Lang wrote: > On Sat, Nov 18, 2023 at 11:08:10AM +0800, Baokun Li wrote: >> On 2023/11/17 22:24, Zorro Lang wrote: >>> Hi Baokun, >>> >>> Thanks for this new coverage, some review points as below ... >>> >> Hi Zorro, >> >> Thank you for your careful review! >> >>>> + >>>> +# Initalize a 4k 100M ext4 fs >>>> +dev_size=$((100 * 1024 * 1024)) >>>> +MKFS_OPTIONS="-b 4096 $MKFS_OPTIONS" _scratch_mkfs_sized $dev_size \ >>>> + >>$seqres.full 2>&1 || _fail "mkfs failed" >>> Can we use bsize=$(_get_file_block_size ....) to get the real block size, >>> to avoid use a specific mkfs option? >>> If so, my second question is if this case can be a generic case. The test >>> steps look common enough, I'm glad to see what will happen on other >>> filesystems through this test. >> The reason for specifying 4096 for formatting here is that mkfs.ext4 >> specifies a >> default block size of 1024 when the disk image is 100M. > Is the reproducer related with the block size. If it's not, we can use > "bsize=$(_get_file_block_size $SCRATCH_MNT)" to get the block size, and change > later 4096 to $bsize. This problem is really hard to reproduce when the block size is 1024, but the good thing is that the default block size specified in _scratch_mkfs_sized() is 4096, so we can leave the block size of 4096 unspecified here. > >> Although these operations appear to be generic scenarios, the reproduction >> of >> this problem relies on ext4's pre-allocation mechanism. Block allocation >> requests >> are scaled up in ext4_mb_normalize_request(), and the extra blocks are used >> for >> preallocation to reduce fragmentation. Therefore, this test case is placed >> only in >> the ext4 test suite. > Sure it's a reproducer for ext4, but it can be run for other filesystems > which support falloc and finsert. And: > _require_xfs_io_command "falloc" > _require_xfs_io_command "finsert" > will make sure the current FSTYP supports these two features. So it can > be a bug coverage for ext4, and a generic test case for other fs. Totally agree, I'll put it in generic test suite in next version, the execution of this use case takes only 1-2s, it doesn't seem to have any impact. >>>> + >>>> +_scratch_mount >>>> + >>>> +# Reserve 1M space >>>> +$XFS_IO_PROG -f -c "falloc 0 1M" "${SCRATCH_MNT}/tmp" >> $seqres.full 2>&1 >>>> + >>>> +# Create a file with logical block numbers close to overflow >>>> +$XFS_IO_PROG -f -c "falloc 0 10M" "${SCRATCH_MNT}/file" >> $seqres.full 2>&1 >>>> +$XFS_IO_PROG -f -c "finsert 1M 16777203M" "${SCRATCH_MNT}/file" >> $seqres.full 2>&1 >>> _require_xfs_io_command "finsert" >> Okay. >>>> + >>>> +# Filling up the free space ensures that the pre-allocated space is the reserved space. >>>> +$XFS_IO_PROG -f -c "falloc 0 80388096" "${SCRATCH_MNT}/fill" >> $seqres.full 2>&1 >>> Can we make sure this step fill the whole free space? There's a helper in >>> common/populate named _fill_fs, please check if it's what you want? >> The remaining space for a 100M 4k ext4 image after the previous operations >> is >> 80388096, so we can confirm that we can fill the entire free space here. >> Of course, using _fill_fs is also workable, but it's faster to do it in a >> single fallocate. > I'm not sure how the reservation works, if there're 90M free space, and you > try to reserve 90+M, will once fallocate calling trys to reserve each free > blocks, before returning error? If it's not, I think the _fill_fs might be > what you want. > > Thanks, > Zorro ext4_fallocate will try to allocate all free blocks if the size to be allocated exceeds the free space on the filesystem, but will still return an error. I've tested _fill_fs and it works well too. I will use _fill_fs in the next release to make this use case more generic. Thanks! -- With Best Regards, Baokun Li . ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2023-11-20 3:44 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2023-10-28 7:01 [PATCH] ext4: Regression test of ext4_lblk_t overflow Baokun Li 2023-11-17 14:24 ` Zorro Lang 2023-11-18 3:08 ` Baokun Li 2023-11-19 13:14 ` Zorro Lang 2023-11-20 3:44 ` Baokun Li
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox