[PATCH] xfstests: generic/315: add one more sync and more output

[PATCH] xfstests: generic/315: add one more sync and more output

[Josef Bacik]

So df in btrfs is tricky at best, and relying on it for accurate information is
not great, but it's the best way to verify this test.  So we need to add another
sync to make sure the pinned blocks are all freed up and the df space is really
really accurate, otherwise we end up with this test failling because the df
after the test is slightly off (in my case it was like 36kb off).  With this
patch I'm not seeing random failures of this test.  Thanks,

Signed-off-by: Josef Bacik <jbacik@fusionio.com>
---
 tests/generic/315 |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/tests/generic/315 b/tests/generic/315
index 7cfc40d..7c55b8a 100644
--- a/tests/generic/315
+++ b/tests/generic/315
@@ -70,10 +70,11 @@ fsize=`ls -l $TEST_DIR/testfile.$seq | awk '{print $5}'`
 # Truncate the file size back to 0
 truncate -s 0 $TEST_DIR/testfile.$seq
 sync
+sync
 
 # Preallocated disk space should be released
 avail_done=`df -P $TEST_DIR | awk 'END {print $4}'`
-[ "$avail_done" -eq "$avail_begin" ] || _fail "Available disk space ($avail_done KiB)"
+[ "$avail_done" -eq "$avail_begin" ] || _fail "Available disk space ($avail_done KiB) wanted ($avail_begin KiB)"
 
 # success, all done
 exit
-- 
1.7.7.6

Re: [PATCH] xfstests: generic/315: add one more sync and more output

[Eric Sandeen]

On 7/29/13 12:21 PM, Josef Bacik wrote:
> So df in btrfs is tricky at best, and relying on it for accurate information is
> not great, but it's the best way to verify this test.  So we need to add another
> sync to make sure the pinned blocks are all freed up and the df space is really
> really accurate, otherwise we end up with this test failling because the df
> after the test is slightly off (in my case it was like 36kb off).  With this
> patch I'm not seeing random failures of this test.  Thanks,

Honest question: does one more sync make this deterministic, or is it a best-effort, um, hack?

-Eric

> Signed-off-by: Josef Bacik <jbacik@fusionio.com>
> ---
>  tests/generic/315 |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/tests/generic/315 b/tests/generic/315
> index 7cfc40d..7c55b8a 100644
> --- a/tests/generic/315
> +++ b/tests/generic/315
> @@ -70,10 +70,11 @@ fsize=`ls -l $TEST_DIR/testfile.$seq | awk '{print $5}'`
>  # Truncate the file size back to 0
>  truncate -s 0 $TEST_DIR/testfile.$seq
>  sync
> +sync
>  
>  # Preallocated disk space should be released
>  avail_done=`df -P $TEST_DIR | awk 'END {print $4}'`
> -[ "$avail_done" -eq "$avail_begin" ] || _fail "Available disk space ($avail_done KiB)"
> +[ "$avail_done" -eq "$avail_begin" ] || _fail "Available disk space ($avail_done KiB) wanted ($avail_begin KiB)"
>  
>  # success, all done
>  exit
> 

Re: [PATCH] xfstests: generic/315: add one more sync and more output

[Eric Sandeen]

On 7/29/13 12:31 PM, Eric Sandeen wrote:
> Honest question: does one more sync make this deterministic, or is it a best-effort, um, hack?

I'm not quite sure why even 1 sync is needed.  :(

I'm not sure what bug this is trying to test; if you need 2 syncs for global space stats to accurately reflect the fact that you chopped off the end of a block, maybe that's ... still a bug?

Or if it's just the big-hammer question of "does the truncated space *ever* get freed?" then maybe umount/remount/check would tell you that more definitively.

-Eric

Re: [PATCH] xfstests: generic/315: add one more sync and more output

[Josef Bacik]

On Mon, Jul 29, 2013 at 12:38:25PM -0500, Eric Sandeen wrote:
> On 7/29/13 12:31 PM, Eric Sandeen wrote:
> > Honest question: does one more sync make this deterministic, or is it a best-effort, um, hack?
> 
> I'm not quite sure why even 1 sync is needed.  :(
> 

Because of COW, we won't free up the data space until the transaction commits
because it is pinned, so doing the truncate and then immediately doing df will
show no difference.

> I'm not sure what bug this is trying to test; if you need 2 syncs for global space stats to accurately reflect the fact that you chopped off the end of a block, maybe that's ... still a bug?
> 

No, it's just COW for you, in this case we do our sync, stuff gets updated and
some metadata is cow'ed for once reason or another and now df doesn't quite
match up (in my case it was off by like 9 blocks), doing a second sync clears
these out and then df's match.

> Or if it's just the big-hammer question of "does the truncated space *ever* get freed?" then maybe umount/remount/check would tell you that more definitively.

Yeah but I think I'll do what you suggested on IRC and just use _within_range.
Thanks,

Josef