Btrfs devel - Jul 2013 - [PATCH] xfstests: generic/315: add one more sync and more output

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

--
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

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

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

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