[LTP] [RFC PATCH] fallocate05: increase the fallocate and defallocate size

Li Wang liwang@redhat.com
Wed Sep 22 07:03:32 CEST 2021


Hi Ralph,

On Wed, Sep 22, 2021 at 4:34 AM Ralph Siemsen <ralph.siemsen@linaro.org>
wrote:

> Hello,
>
> On Tue, Aug 17, 2021 at 06:46:25PM +0800, Li Wang wrote:
> >
> >diff --git a/testcases/kernel/syscalls/fallocate/fallocate05.c
> b/testcases/kernel/syscalls/fallocate/fallocate05.c
> >index 55ec1aee4..74bfa4861 100644
> >--- a/testcases/kernel/syscalls/fallocate/fallocate05.c
> >+++ b/testcases/kernel/syscalls/fallocate/fallocate05.c
> >@@ -26,8 +26,8 @@
> > #include "lapi/fallocate.h"
> >
> > #define MNTPOINT "mntpoint"
> >-#define FALLOCATE_BLOCKS 16
> >-#define DEALLOCATE_BLOCKS 4
> >+#define FALLOCATE_BLOCKS 256
> >+#define DEALLOCATE_BLOCKS 64
> > #define TESTED_FLAGS "fallocate(FALLOC_FL_PUNCH_HOLE |
> FALLOC_FL_KEEP_SIZE)"
> >
> > static char *buf;
>
> This change appears seems to be causing fallocate05 test to reliably
> trigger OOM (out of memory) on my test machine, which has only 256MB
> RAM.
>

Thanks for reporting the failure. We purposely increase the size of
fallocate
to reduce interference from metadata changing. But not clear how much
size should be a proper value for a small system.

Can you try with decrease the number of FALLOCATE_BLOCKS?

i.e.

#define FALLOCATE_BLOCKS 64
#define DEALLOCATE_BLOCKS 16

Or, what about other multiple sizes, test result?


-- 
Regards,
Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20210922/d6eb320a/attachment.htm>


More information about the ltp mailing list