I was wondering if anyone has any experience with how long a "zfs destroy" of about 40 TB should take? So far, it has been about an hour... Is there any good way to tell if it is working or if it is hung? Doing a "zfs list" just hangs. If you do a more specific zfs list, then it is okay... zfs list pool/another-fs Thanks, David -- This message posted from opensolaris.org
A few more details: The system is a Sun x4600 running Solaris 10 Update 4. -- This message posted from opensolaris.org
David Smith wrote:> I was wondering if anyone has any experience with how long a "zfs destroy" of about 40 TB should take? So far, it has been about an hour... Is there any good way to tell if it is working or if it is hung? > > Doing a "zfs list" just hangs. If you do a more specific zfs list, then it is okay... zfs list pool/another-fs > > Thanks, > > David >I can''t voice to something like 40 TB, but I can share a related story (on Solaris 10u5). A couple days ago, I tried to zfs destroy a clone of a snapshot of a 191 GB zvol. It didn''t complete right away, but the machine appeared to continue working on it, so I decided to let it go overnight (it was near the end of the day). Well, by about 4:00 am the next day, the machine had completely ran out of memory and hung. When I came in, I forced a sync from prom to get it back up. While it was booting, it stopped during (I think) the zfs initialization part, where it ran the disks for about 10 minutes before continuing. When the machine was back up, everything appeared to be ok. The clone was still there, although usage had changed to zero. I ended up patching the machine up to the latest u6 kernel + zfs patch (138888-01 + 139579-01). After that, the zfs destroy went off without a hitch. I turned up bug 6606810 ''zfs destroy <volume> is taking hours to complete'' which is supposed to be fixed by 139579-01. I don''t know if that was the cause of my issue or not. I''ve got a 2GB kernel dump if anyone is interested in looking. -Brian -- --------------------------------------------------- Brian H. Nelson Youngstown State University System Administrator Media and Academic Computing bnelson[at]cis.ysu.edu ---------------------------------------------------
On Thu, 2009-01-08 at 13:26 -0500, Brian H. Nelson wrote:> David Smith wrote: > > I was wondering if anyone has any experience with how long a "zfs destroy" of about 40 TB should take? So far, it has been about an hour... Is there any good way to tell if it is working or if it is hung? > > > > Doing a "zfs list" just hangs. If you do a more specific zfs list, then it is okay... zfs list pool/another-fs > > > > Thanks, > > > > David > > > > I can''t voice to something like 40 TB, but I can share a related story > (on Solaris 10u5). > > A couple days ago, I tried to zfs destroy a clone of a snapshot of a 191 > GB zvol. It didn''t complete right away, but the machine appeared to > continue working on it, so I decided to let it go overnight (it was near > the end of the day). Well, by about 4:00 am the next day, the machine > had completely ran out of memory and hung. When I came in, I forced a > sync from prom to get it back up. While it was booting, it stopped > during (I think) the zfs initialization part, where it ran the disks for > about 10 minutes before continuing. When the machine was back up, > everything appeared to be ok. The clone was still there, although usage > had changed to zero. > > I ended up patching the machine up to the latest u6 kernel + zfs patch > (138888-01 + 139579-01). After that, the zfs destroy went off without a > hitch. > > I turned up bug 6606810 ''zfs destroy <volume> is taking hours to > complete'' which is supposed to be fixed by 139579-01. I don''t know if > that was the cause of my issue or not. I''ve got a 2GB kernel dump if > anyone is interested in looking. > > -Brian >Brian, Thanks for the reply. I''ll take a look at the 139579-01 patch. Perhaps as well a Sun engineer will comment about this issue being fixed with patches, etc. David
David W. Smith wrote:> On Thu, 2009-01-08 at 13:26 -0500, Brian H. Nelson wrote: > >> David Smith wrote: >> >>> I was wondering if anyone has any experience with how long a "zfs destroy" of about 40 TB should take? So far, it has been about an hour... Is there any good way to tell if it is working or if it is hung? >>> >>> Doing a "zfs list" just hangs. If you do a more specific zfs list, then it is okay... zfs list pool/another-fs >>> >>> Thanks, >>> >>> David >>> >>> >> I can''t voice to something like 40 TB, but I can share a related story >> (on Solaris 10u5). >> >> A couple days ago, I tried to zfs destroy a clone of a snapshot of a 191 >> GB zvol. It didn''t complete right away, but the machine appeared to >> continue working on it, so I decided to let it go overnight (it was near >> the end of the day). Well, by about 4:00 am the next day, the machine >> had completely ran out of memory and hung. When I came in, I forced a >> sync from prom to get it back up. While it was booting, it stopped >> during (I think) the zfs initialization part, where it ran the disks for >> about 10 minutes before continuing. When the machine was back up, >> everything appeared to be ok. The clone was still there, although usage >> had changed to zero. >> >> I ended up patching the machine up to the latest u6 kernel + zfs patch >> (138888-01 + 139579-01). After that, the zfs destroy went off without a >> hitch. >> >> I turned up bug 6606810 ''zfs destroy <volume> is taking hours to >> complete'' which is supposed to be fixed by 139579-01. I don''t know if >> that was the cause of my issue or not. I''ve got a 2GB kernel dump if >> anyone is interested in looking. >> >> -Brian >> >> > > Brian, > > Thanks for the reply. I''ll take a look at the 139579-01 patch. Perhaps > as well a Sun engineer will comment about this issue being fixed with > patches, etc. >My pleasure :-). 6606810 was closed as a dup of 6573681 which was fixed in NV 94 and patch 139579-01. http://bugs.opensolaris.org/view_bug.do?bug_id=6606810 http://bugs.opensolaris.org/view_bug.do?bug_id=6573681 http://sunsolve.sun.com/search/document.do?assetkey=1-21-139579-01-1 -- richard