Discussion:
cannot destroy, volume is busy
(too old to reply)
John D Groenveld
2013-02-21 16:02:01 UTC
Permalink
# zfs list -t vol
NAME USED AVAIL REFER MOUNTPOINT
rpool/dump 4.00G 99.9G 4.00G -
rpool/foo128 66.2M 100G 16K -
rpool/swap 4.00G 99.9G 4.00G -

# zfs destroy rpool/foo128
cannot destroy 'rpool/foo128': volume is busy

I checked that the volume is not a dump or swap device
and that iSCSI is disabled.

On Solaris 11.1, how would I determine what's busying it?

John
***@acm.org
Jim Klimov
2013-02-21 19:21:17 UTC
Permalink
Post by John D Groenveld
# zfs list -t vol
NAME USED AVAIL REFER MOUNTPOINT
rpool/dump 4.00G 99.9G 4.00G -
rpool/foo128 66.2M 100G 16K -
rpool/swap 4.00G 99.9G 4.00G -
# zfs destroy rpool/foo128
cannot destroy 'rpool/foo128': volume is busy
Can anything local be holding it (databases, virtualbox, etc)?
Can there be any clones, held snapshots or an ongoing "zfs send"?
(Perhaps an aborted "send" left a hold?)

Sometimes I have had a bug with a filesystem dataset becoming so "busy"
that I couldn't snapshot it. Unmounting and mounting it back usually
helped. This was back in the days of SXCE snv_117 and Solaris 10u8,
and the bug often popped up in conjunction with LiveUpgrade. I believe
this particular issue was solved since, but maybe something new like it
has appeared?..

Hopefully some on-list gurus might walk you through use of a debugger
or dtrace to track which calls are being made by "zfs destroy" and lead
it to conclude that the dataset is busy?.. I really only know to use
"truss -f -l progname params" which helps most of the time, and would
love to learn the modern equivalents which give more insights into code.

//Jim
Richard Elling
2013-02-21 20:44:34 UTC
Permalink
Post by John D Groenveld
# zfs list -t vol
NAME USED AVAIL REFER MOUNTPOINT
rpool/dump 4.00G 99.9G 4.00G -
rpool/foo128 66.2M 100G 16K -
rpool/swap 4.00G 99.9G 4.00G -
# zfs destroy rpool/foo128
cannot destroy 'rpool/foo128': volume is busy
I checked that the volume is not a dump or swap device
and that iSCSI is disabled.
The iSCSI service is not STMF. STMF will need to be disabled, or the volume no longer
used by STMF.

iSCSI service is svc:/network/iscsi/target:default
STMF service is svc:/system/stmf:default
Post by John D Groenveld
On Solaris 11.1, how would I determine what's busying it?
One would think that fuser would work, but in my experience, fuser rarely does
what I expect.

If you suspect STMF, then try
stmfadm list-lu -v

-- richard

--

***@RichardElling.com
+1-760-896-4422
John D Groenveld
2013-02-21 21:00:58 UTC
Permalink
The iSCSI service is not STMF. STMF will need to be disabled, or the =
volume no longer
used by STMF.
iSCSI service is svc:/network/iscsi/target:default
STMF service is svc:/system/stmf:default
Thank you for the gentle nudge with the clue stick, forgot the
process I used...
<URL:http://docs.oracle.com/cd/E26502_01/html/E29007/gaypf.html>
One would think that fuser would work, but in my experience, fuser =
rarely does
what I expect.
fuser(1M) came up blank.
If you suspect STMF, then try
stmfadm list-lu -v
Bingo!
Deleted the LU and destroyed the volume.

John
***@acm.org

Loading...