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 _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
