All of lore.kernel.org
 help / color / mirror / Atom feed
* [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.