# 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 groenveld at acm.org
On 2013-02-21 17:02, John D Groenveld wrote:> # 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 busyCan 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
On Feb 21, 2013, at 8:02 AM, John D Groenveld <jdg117 at elvis.arl.psu.edu> wrote:> # 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> > 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 -- Richard.Elling at RichardElling.com +1-760-896-4422 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20130221/568c127c/attachment.html>
In message <7F44E458-5D27-42B6-AC81-7F4FF61D6CA8 at gmail.com>, Richard Elling wri tes:>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:defaultThank 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 -vBingo! Deleted the LU and destroyed the volume. John groenveld at acm.org