async_destroy_001_pos fails because it doesn't see 'freeing' prop populated
Test: /opt/zfs-tests/tests/functional/features/async_destroy/async_destroy_001_pos (run as root) [03:04] [FAIL]
13:54:09.34 ASSERTION: async_destroy can suspend and resume traversal
13:54:09.39 SUCCESS: /usr/sbin/zfs create -o recordsize=512 -o compression=off testpool.100876/async_destroy
13:56:42.71 SUCCESS: /usr/bin/dd bs=1024k count=2048 if=/dev/zero of=/testpool.100876/async_destroy/file
13:57:13.77 SUCCESS: /usr/sbin/zfs destroy testpool.100876/async_destroy
13:57:13.83 ERROR: test 0 -gt 5 exited 1
13:57:13.84 NOTE: Performing local cleanup via log_onexit (cleanup)
This failure was seen in os-zfs-test jobs 2490 and 2496, from Fhloston precommit builds 42 and 43. I've verified that in fact the freeing property does show non zero values after an fs destroy. The problem seems to be that there's a small window after the destroy command returns during which the property is 0 and the test assumes this is not so. Running the test on 3 VMs in a loop, I've only been able to reproduce it once, and then only on a debug build - this may be why it wasn't seen in the nightly runs.
Fix will be to watch for non-zero values without assuming there's no window where the value can be 0 after the destroy command returns.
Updated by Electric Monk almost 4 years ago
- % Done changed from 0 to 100
- Status changed from New to Closed
commit db2417522bcef7cf091649ee369330ecefbaf183 Author: John Wren Kennedy <firstname.lastname@example.org> Date: 2015-10-03T21:33:48.000Z 6249 async_destroy_001_pos fails because it doesn't see 'freeing' prop populated Reviewed by: Matthew Ahrens <email@example.com> Reviewed by: Prakash Surya <firstname.lastname@example.org> Approved by: Richard Lowe <email@example.com>