On a Solaris 11 (SR3) system I have a zfs destroy process what appears to be doing nothing and can''t be killed. It has used 5 seconds of CPU in a day and a half, but truss -p won''t attach. No data appears to have been removed. The dataset (but not the pool) is busy. I thought this was an old problem that was fixed long ago in Solaris 10 (I had several temporary patches over the years), but it appears to be alive and well. Any hints? -- Ian.
> From: zfs-discuss-bounces at opensolaris.org [mailto:zfs-discuss- > bounces at opensolaris.org] On Behalf Of Ian Collins > > On a Solaris 11 (SR3) system I have a zfs destroy process what appears > to be doing nothing and can''t be killed. It has used 5 seconds of CPU > in a day and a half, but truss -p won''t attach. No data appears to have > been removed. The dataset (but not the pool) is busy. > > I thought this was an old problem that was fixed long ago in Solaris 10 > (I had several temporary patches over the years), but it appears to be > alive and well.How big is your dataset? On what type of disks/pool? zfs destroy does indeed take time (unlike zpool destroy.) A couple of days might be normal expected behavior, depending on your configuration. You didn''t specify if you have dedup... Dedup will greatly hurt your zfs destroy speed, too. That being said, sometimes things go wrong, and I don''t have any suggestion for you to determine if yours is behaving "as expected." Or not.
On 05/ 8/12 08:36 AM, Edward Ned Harvey wrote:>> From: zfs-discuss-bounces at opensolaris.org [mailto:zfs-discuss- >> bounces at opensolaris.org] On Behalf Of Ian Collins >> >> On a Solaris 11 (SR3) system I have a zfs destroy process what appears >> to be doing nothing and can''t be killed. It has used 5 seconds of CPU >> in a day and a half, but truss -p won''t attach. No data appears to have >> been removed. The dataset (but not the pool) is busy. >> >> I thought this was an old problem that was fixed long ago in Solaris 10 >> (I had several temporary patches over the years), but it appears to be >> alive and well. > How big is your dataset?Small, 15GB.> On what type of disks/pool?Single iSCSI volume.> zfs destroy does indeed take time (unlike zpool destroy.) A couple of days > might be normal expected behavior, depending on your configuration. You > didn''t specify if you have dedup... Dedup will greatly hurt your zfs > destroy speed, too.I''ve yet to find a system with enough RAM to make dedup worthwhile! After 5 days, a grand total of 1.2GB has been removed and the process responded to kill -9 and exited... I just re-ran the command it it completed in 2 seconds. Well odd. -- Ian.