[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