| Message ID | 1375118463-29654-1-git-send-email-jbacik@fusionio.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
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
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
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(-)