Project

General

Profile

Bug #6249

async_destroy_001_pos fails because it doesn't see 'freeing' prop populated

Added by Matthew Ahrens over 5 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Normal
Category:
zfs - Zettabyte File System
Start date:
2015-09-20
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage
Gerrit CR:

Description

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

Also available in: Atom PDF