I think you can kill the destroy command process using traditional methods.
Perhaps your slowness issue is because the pool is an older format. I've not had these problems since upgrading to the zfs version that comes default with 2008.11 On Fri, Feb 13, 2009 at 4:14 PM, David Dyer-Bennet <d...@dd-b.net> wrote: > This shouldn't be taking anywhere *near* half an hour. The snapshots > differ trivially, by one or two files and less than 10k of data (they're > test results from working on my backup script). But so far, it's still > sitting there after more than half an hour. > > local...@fsfs:~/src/bup2# zfs destroy ruin/export > cannot destroy 'ruin/export': filesystem has children > use '-r' to destroy the following datasets: > ruin/export/h...@bup-20090210-202557utc > ruin/export/h...@20090210-213902utc > ruin/export/home/local...@first > ruin/export/home/local...@second > ruin/export/home/local...@bup-20090210-202557utc > ruin/export/home/local...@20090210-213902utc > ruin/export/home/localddb > ruin/export/home > local...@fsfs:~/src/bup2# zfs destroy -r ruin/export > > It's still hung. > > Ah, here's zfs list output from shortly before I started the destroy: > > ruin 474G 440G 431G /backups/ruin > ruin/export 35.0M 440G 18K /backups/ruin/export > ruin/export/home 35.0M 440G 19K /export/home > ruin/export/home/localddb 35M 440G 27.8M /export/home/localddb > > As you can see, the ruin/export/home filesystem (and subs) is NOT large. > > iostat shows no activity on pool ruin over a minute. > > local...@fsfs:~$ pfexec zpool iostat ruin 10 > capacity operations bandwidth > pool used avail read write read write > ---------- ----- ----- ----- ----- ----- ----- > ruin 474G 454G 10 0 1.13M 840 > ruin 474G 454G 0 0 0 0 > ruin 474G 454G 0 0 0 0 > ruin 474G 454G 0 0 0 0 > ruin 474G 454G 0 0 0 0 > ruin 474G 454G 0 0 0 0 > ruin 474G 454G 0 0 0 0 > ruin 474G 454G 0 0 0 0 > ruin 474G 454G 0 0 0 0 > > The pool still thinks it is healthy. > > local...@fsfs:~$ zpool status -v ruin > pool: ruin > state: ONLINE > status: The pool is formatted using an older on-disk format. The pool can > still be used, but some features are unavailable. > action: Upgrade the pool using 'zpool upgrade'. Once this is done, the > pool will no longer be accessible on older software versions. > scrub: scrub completed after 4h42m with 0 errors on Mon Feb 9 19:10:49 2009 > config: > > NAME STATE READ WRITE CKSUM > ruin ONLINE 0 0 0 > c7t0d0 ONLINE 0 0 0 > > errors: No known data errors > > There is still a process out there trying to run that destroy. It doesn't > appear to be using much cpu time. > > local...@fsfs:~$ ps -ef | grep zfs > localddb 7291 7228 0 15:10:56 pts/4 0:00 grep zfs > root 7223 7101 0 14:18:27 pts/3 0:00 zfs destroy -r ruin/export > > Running 2008.11. > > local...@fsfs:~$ uname -a > SunOS fsfs 5.11 snv_101b i86pc i386 i86pc Solaris > > Any suggestions? Eventually I'll kill the process by the gentlest way > that works, I suppose (if it doesn't complete). > -- > David Dyer-Bennet, d...@dd-b.net; http://dd-b.net/ > Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/ > Photos: http://dd-b.net/photography/gallery/ > Dragaera: http://dragaera.info > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
