xfstests: generic/315: add one more sync and more output
diff mbox

Message ID 1375118463-29654-1-git-send-email-jbacik@fusionio.com
State Not Applicable
Headers show

Commit Message

Josef Bacik July 29, 2013, 5:21 p.m. UTC
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(-)

Comments

Eric Sandeen July 29, 2013, 5:31 p.m. UTC | #1
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
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Eric Sandeen July 29, 2013, 5:38 p.m. UTC | #2
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
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Josef Bacik July 29, 2013, 6:25 p.m. UTC | #3
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
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch
diff mbox

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