* [LTP] [PATCH] fallocate05: increase FALLOCATE_SIZE
@ 2019-11-18 16:08 Jan Stancek
2019-11-18 16:18 ` Martin Doucha
` (2 more replies)
0 siblings, 3 replies; 9+ messages in thread
From: Jan Stancek @ 2019-11-18 16:08 UTC (permalink / raw)
To: ltp
write() returning ENOSPC doesn't guarantee that filesystem after
some internal book-keeping, flushing, finishing transactions, etc.
won't still find some extra space.
Increase FALLOCATE_SIZE to minimize chance of hitting sporadic
failures when that happens.
Thanks to Carlos Maiolino and Eric Sandeen for their comments
and suggestions.
Fixes #610
Signed-off-by: Jan Stancek <jstancek@redhat.com>
---
testcases/kernel/syscalls/fallocate/fallocate05.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/testcases/kernel/syscalls/fallocate/fallocate05.c b/testcases/kernel/syscalls/fallocate/fallocate05.c
index 50c610c448ba..17034e5b11e7 100644
--- a/testcases/kernel/syscalls/fallocate/fallocate05.c
+++ b/testcases/kernel/syscalls/fallocate/fallocate05.c
@@ -17,7 +17,7 @@
#include "lapi/fallocate.h"
#define MNTPOINT "mntpoint"
-#define FALLOCATE_SIZE 8192
+#define FALLOCATE_SIZE (1024*1024)
#define TESTED_FLAGS "fallocate(FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE)"
static int fd;
--
1.8.3.1
^ permalink raw reply related [flat|nested] 9+ messages in thread
* [LTP] [PATCH] fallocate05: increase FALLOCATE_SIZE
2019-11-18 16:08 [LTP] [PATCH] fallocate05: increase FALLOCATE_SIZE Jan Stancek
@ 2019-11-18 16:18 ` Martin Doucha
2019-11-19 5:45 ` Li Wang
2019-11-18 16:19 ` Cyril Hrubis
2019-11-19 5:34 ` Li Wang
2 siblings, 1 reply; 9+ messages in thread
From: Martin Doucha @ 2019-11-18 16:18 UTC (permalink / raw)
To: ltp
On 11/18/19 5:08 PM, Jan Stancek wrote:
> write() returning ENOSPC doesn't guarantee that filesystem after
> some internal book-keeping, flushing, finishing transactions, etc.
> won't still find some extra space.
>
> Increase FALLOCATE_SIZE to minimize chance of hitting sporadic
> failures when that happens.
We're planning to rewrite fallocate05 this week and FALLOCATE_SIZE will
be removed entirely. The test must use a multiple of the real file
system block size, otherwise it'll test different things on different
platforms.
--
Martin Doucha mdoucha@suse.cz
QA Engineer for Software Maintenance
SUSE LINUX, s.r.o.
CORSO IIa
Krizikova 148/34
186 00 Prague 8
Czech Republic
^ permalink raw reply [flat|nested] 9+ messages in thread
* [LTP] [PATCH] fallocate05: increase FALLOCATE_SIZE
2019-11-18 16:08 [LTP] [PATCH] fallocate05: increase FALLOCATE_SIZE Jan Stancek
2019-11-18 16:18 ` Martin Doucha
@ 2019-11-18 16:19 ` Cyril Hrubis
2019-11-19 5:34 ` Li Wang
2 siblings, 0 replies; 9+ messages in thread
From: Cyril Hrubis @ 2019-11-18 16:19 UTC (permalink / raw)
To: ltp
Hi!
> write() returning ENOSPC doesn't guarantee that filesystem after
> some internal book-keeping, flushing, finishing transactions, etc.
> won't still find some extra space.
>
> Increase FALLOCATE_SIZE to minimize chance of hitting sporadic
> failures when that happens.
>
> Thanks to Carlos Maiolino and Eric Sandeen for their comments
> and suggestions.
Acked.
--
Cyril Hrubis
chrubis@suse.cz
^ permalink raw reply [flat|nested] 9+ messages in thread
* [LTP] [PATCH] fallocate05: increase FALLOCATE_SIZE
2019-11-18 16:08 [LTP] [PATCH] fallocate05: increase FALLOCATE_SIZE Jan Stancek
2019-11-18 16:18 ` Martin Doucha
2019-11-18 16:19 ` Cyril Hrubis
@ 2019-11-19 5:34 ` Li Wang
2019-11-19 8:13 ` Jan Stancek
2 siblings, 1 reply; 9+ messages in thread
From: Li Wang @ 2019-11-19 5:34 UTC (permalink / raw)
To: ltp
Hi Jan,
On Tue, Nov 19, 2019 at 12:08 AM Jan Stancek <jstancek@redhat.com> wrote:
> write() returning ENOSPC doesn't guarantee that filesystem after
> some internal book-keeping, flushing, finishing transactions, etc.
> won't still find some extra space.
>
Thanks for the patch, I have drafted a similar one but you sent out first
:).
Another patch I was thinking is to enhance the tst_fill_fs routine, which
as Eric suggested, makes more reliably to get to a full filesystem.
Something like what xfstest does to cut the trial write size in half and
try again until the size is less than the filesystem block size.
Comments?
--- a/lib/tst_fill_fs.c
+++ b/lib/tst_fill_fs.c
@@ -6,6 +6,7 @@
#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
+#include <sys/statvfs.h>
#define TST_NO_DEFAULT_MAIN
#include "tst_test.h"
@@ -19,6 +20,8 @@ void tst_fill_fs(const char *path, int verbose)
size_t len;
ssize_t ret;
int fd;
+ struct statvfs fi;
+ statvfs(path, &fi);
for (;;) {
len = random() % (1024 * 102400);
@@ -41,6 +44,12 @@ void tst_fill_fs(const char *path, int verbose)
ret = write(fd, buf, MIN(len, sizeof(buf)));
if (ret < 0) {
+ if (errno == ENOSPC) {
+ len /= 2;
+ if (len >= fi.f_bsize)
+ continue;
+ }
+
SAFE_CLOSE(fd);
if (errno != ENOSPC)
>
> Increase FALLOCATE_SIZE to minimize chance of hitting sporadic
> failures when that happens.
>
> Thanks to Carlos Maiolino and Eric Sandeen for their comments
> and suggestions.
>
> Fixes #610
> Signed-off-by: Jan Stancek <jstancek@redhat.com>
>
Reviewed-by: Li Wang <liwang@redhat.com>
> ---
> testcases/kernel/syscalls/fallocate/fallocate05.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/testcases/kernel/syscalls/fallocate/fallocate05.c
> b/testcases/kernel/syscalls/fallocate/fallocate05.c
> index 50c610c448ba..17034e5b11e7 100644
> --- a/testcases/kernel/syscalls/fallocate/fallocate05.c
> +++ b/testcases/kernel/syscalls/fallocate/fallocate05.c
> @@ -17,7 +17,7 @@
> #include "lapi/fallocate.h"
>
> #define MNTPOINT "mntpoint"
> -#define FALLOCATE_SIZE 8192
> +#define FALLOCATE_SIZE (1024*1024)
> #define TESTED_FLAGS "fallocate(FALLOC_FL_PUNCH_HOLE |
> FALLOC_FL_KEEP_SIZE)"
>
> static int fd;
> --
> 1.8.3.1
>
>
--
Regards,
Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20191119/9aa93bfa/attachment.htm>
^ permalink raw reply [flat|nested] 9+ messages in thread
* [LTP] [PATCH] fallocate05: increase FALLOCATE_SIZE
2019-11-18 16:18 ` Martin Doucha
@ 2019-11-19 5:45 ` Li Wang
0 siblings, 0 replies; 9+ messages in thread
From: Li Wang @ 2019-11-19 5:45 UTC (permalink / raw)
To: ltp
On Tue, Nov 19, 2019 at 12:19 AM Martin Doucha <mdoucha@suse.cz> wrote:
> On 11/18/19 5:08 PM, Jan Stancek wrote:
> > write() returning ENOSPC doesn't guarantee that filesystem after
> > some internal book-keeping, flushing, finishing transactions, etc.
> > won't still find some extra space.
> >
> > Increase FALLOCATE_SIZE to minimize chance of hitting sporadic
> > failures when that happens.
>
> We're planning to rewrite fallocate05 this week and FALLOCATE_SIZE will
> be removed entirely. The test must use a multiple of the real file
> system block size, otherwise it'll test different things on different
> platforms.
>
Sounds good. Thanks!
But it'd be better to merge Jan's patch first because there will still need
time for new patch reviewing.
--
Regards,
Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20191119/2362b5a9/attachment.htm>
^ permalink raw reply [flat|nested] 9+ messages in thread
* [LTP] [PATCH] fallocate05: increase FALLOCATE_SIZE
2019-11-19 5:34 ` Li Wang
@ 2019-11-19 8:13 ` Jan Stancek
2019-11-19 8:59 ` Li Wang
2019-11-19 9:47 ` Martin Doucha
0 siblings, 2 replies; 9+ messages in thread
From: Jan Stancek @ 2019-11-19 8:13 UTC (permalink / raw)
To: ltp
----- Original Message -----
> Another patch I was thinking is to enhance the tst_fill_fs routine, which
> as Eric suggested, makes more reliably to get to a full filesystem.
> Something like what xfstest does to cut the trial write size in half and
> try again until the size is less than the filesystem block size.
>
> Comments?
fallocate05 seems to be the only test using it, but in general I think we
can do that too. Assuming this alone would be reliable, is there any
advantage of running test with small FALLOCATE_SIZE?
>
> --- a/lib/tst_fill_fs.c
> +++ b/lib/tst_fill_fs.c
> @@ -6,6 +6,7 @@
> #include <errno.h>
> #include <stdio.h>
> #include <stdlib.h>
> +#include <sys/statvfs.h>
>
> #define TST_NO_DEFAULT_MAIN
> #include "tst_test.h"
> @@ -19,6 +20,8 @@ void tst_fill_fs(const char *path, int verbose)
> size_t len;
> ssize_t ret;
> int fd;
> + struct statvfs fi;
> + statvfs(path, &fi);
>
> for (;;) {
> len = random() % (1024 * 102400);
> @@ -41,6 +44,12 @@ void tst_fill_fs(const char *path, int verbose)
> ret = write(fd, buf, MIN(len, sizeof(buf)));
>
> if (ret < 0) {
> + if (errno == ENOSPC) {
> + len /= 2;
> + if (len >= fi.f_bsize)
> + continue;
> + }
> +
> SAFE_CLOSE(fd);
>
> if (errno != ENOSPC)
>
>
>
> >
> > Increase FALLOCATE_SIZE to minimize chance of hitting sporadic
> > failures when that happens.
> >
> > Thanks to Carlos Maiolino and Eric Sandeen for their comments
> > and suggestions.
> >
> > Fixes #610
> > Signed-off-by: Jan Stancek <jstancek@redhat.com>
> >
> Reviewed-by: Li Wang <liwang@redhat.com>
Thanks, I pushed this patch for now.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [LTP] [PATCH] fallocate05: increase FALLOCATE_SIZE
2019-11-19 8:13 ` Jan Stancek
@ 2019-11-19 8:59 ` Li Wang
2019-11-19 9:47 ` Martin Doucha
1 sibling, 0 replies; 9+ messages in thread
From: Li Wang @ 2019-11-19 8:59 UTC (permalink / raw)
To: ltp
Hi,
On Tue, Nov 19, 2019 at 4:13 PM Jan Stancek <jstancek@redhat.com> wrote:
>
>
> ----- Original Message -----
> > Another patch I was thinking is to enhance the tst_fill_fs routine, which
> > as Eric suggested, makes more reliably to get to a full filesystem.
> > Something like what xfstest does to cut the trial write size in half and
> > try again until the size is less than the filesystem block size.
> >
> > Comments?
>
> fallocate05 seems to be the only test using it, but in general I think we
>
Thanks, I will format a patch.
> can do that too. Assuming this alone would be reliable, is there any
> advantage of running test with small FALLOCATE_SIZE?
>
Hmm, maybe no, my purpose to shrink the FALLOCATE_SIZE is just to reproduce
the problem. I thought that if the filesystem is not 'really' full, then
the fallocate() should succeed with a smaller size, only for degging.
>
> >
> > --- a/lib/tst_fill_fs.c
> > +++ b/lib/tst_fill_fs.c
> > @@ -6,6 +6,7 @@
> > #include <errno.h>
> > #include <stdio.h>
> > #include <stdlib.h>
> > +#include <sys/statvfs.h>
> >
> > #define TST_NO_DEFAULT_MAIN
> > #include "tst_test.h"
> > @@ -19,6 +20,8 @@ void tst_fill_fs(const char *path, int verbose)
> > size_t len;
> > ssize_t ret;
> > int fd;
> > + struct statvfs fi;
> > + statvfs(path, &fi);
> >
> > for (;;) {
> > len = random() % (1024 * 102400);
> > @@ -41,6 +44,12 @@ void tst_fill_fs(const char *path, int verbose)
> > ret = write(fd, buf, MIN(len, sizeof(buf)));
> >
> > if (ret < 0) {
> > + if (errno == ENOSPC) {
> > + len /= 2;
> > + if (len >= fi.f_bsize)
> > + continue;
> > + }
> > +
> > SAFE_CLOSE(fd);
> >
> > if (errno != ENOSPC)
> >
> >
> >
> > >
> > > Increase FALLOCATE_SIZE to minimize chance of hitting sporadic
> > > failures when that happens.
> > >
> > > Thanks to Carlos Maiolino and Eric Sandeen for their comments
> > > and suggestions.
> > >
> > > Fixes #610
> > > Signed-off-by: Jan Stancek <jstancek@redhat.com>
> > >
> > Reviewed-by: Li Wang <liwang@redhat.com>
>
> Thanks, I pushed this patch for now.
>
>
--
Regards,
Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20191119/539ca4f6/attachment-0001.htm>
^ permalink raw reply [flat|nested] 9+ messages in thread
* [LTP] [PATCH] fallocate05: increase FALLOCATE_SIZE
2019-11-19 8:13 ` Jan Stancek
2019-11-19 8:59 ` Li Wang
@ 2019-11-19 9:47 ` Martin Doucha
2019-11-19 10:02 ` Jan Stancek
1 sibling, 1 reply; 9+ messages in thread
From: Martin Doucha @ 2019-11-19 9:47 UTC (permalink / raw)
To: ltp
On 11/19/19 9:13 AM, Jan Stancek wrote:
>
>
> ----- Original Message -----
>> Another patch I was thinking is to enhance the tst_fill_fs routine, which
>> as Eric suggested, makes more reliably to get to a full filesystem.
>> Something like what xfstest does to cut the trial write size in half and
>> try again until the size is less than the filesystem block size.
>>
>> Comments?
>
> fallocate05 seems to be the only test using it, but in general I think we
> can do that too. Assuming this alone would be reliable, is there any
> advantage of running test with small FALLOCATE_SIZE?
Note that simply increasing FALLOCATE_SIZE will not fix an incorrect
pass when the file system wasn't completely full. Here's the code that
checks whether some blocks were properly fallocate()d:
tst_fill_fs(MNTPOINT, 1);
ret = write(fd, buf, sizeof(buf));
if (ret < 0)
tst_res(TFAIL | TERRNO, "write() failed unexpectedly");
else
tst_res(TPASS, "write() wrote %zu bytes", ret);
If the file system somehow finds a few free blocks after tst_fill_fs()
returns, short write() will still count as a pass.
--
Martin Doucha mdoucha@suse.cz
QA Engineer for Software Maintenance
SUSE LINUX, s.r.o.
CORSO IIa
Krizikova 148/34
186 00 Prague 8
Czech Republic
^ permalink raw reply [flat|nested] 9+ messages in thread
* [LTP] [PATCH] fallocate05: increase FALLOCATE_SIZE
2019-11-19 9:47 ` Martin Doucha
@ 2019-11-19 10:02 ` Jan Stancek
0 siblings, 0 replies; 9+ messages in thread
From: Jan Stancek @ 2019-11-19 10:02 UTC (permalink / raw)
To: ltp
----- Original Message -----
> > ----- Original Message -----
> > fallocate05 seems to be the only test using it, but in general I think we
> > can do that too. Assuming this alone would be reliable, is there any
> > advantage of running test with small FALLOCATE_SIZE?
>
> Note that simply increasing FALLOCATE_SIZE will not fix an incorrect
> pass when the file system wasn't completely full. Here's the code that
> checks whether some blocks were properly fallocate()d:
>
> tst_fill_fs(MNTPOINT, 1);
> ret = write(fd, buf, sizeof(buf));
> if (ret < 0)
> tst_res(TFAIL | TERRNO, "write() failed unexpectedly");
> else
> tst_res(TPASS, "write() wrote %zu bytes", ret);
>
> If the file system somehow finds a few free blocks after tst_fill_fs()
> returns, short write() will still count as a pass.
That is good point, but that seems like issue that existed even with
8k FALLOCATE_SIZE, right?
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2019-11-19 10:02 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-18 16:08 [LTP] [PATCH] fallocate05: increase FALLOCATE_SIZE Jan Stancek
2019-11-18 16:18 ` Martin Doucha
2019-11-19 5:45 ` Li Wang
2019-11-18 16:19 ` Cyril Hrubis
2019-11-19 5:34 ` Li Wang
2019-11-19 8:13 ` Jan Stancek
2019-11-19 8:59 ` Li Wang
2019-11-19 9:47 ` Martin Doucha
2019-11-19 10:02 ` Jan Stancek
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.