[OmniOS-discuss] ZFS pool allocation remains after removing all files

[Filip Marvan]

Hello,

maybe you will have to enable compression on that ZVOL, and rewrite that
disk with zeroes from client. Because your pool propably don't even know
from vmware client, that you delete your data.

Filip

--------------------------------------------------
Date: Tue, 7 Oct 2014 23:00:47 +0000
From: Rune Tipsmark <rt at steait.net>
To: omnios-discuss <omnios-discuss at lists.omniti.com>
Subject: [OmniOS-discuss] ZFS pool allocation remains after removing
	all	files
Message-ID: <3dde7c3ae1994829b588d3df09855cf0 at EX1301.steait.net>
Content-Type: text/plain; charset="us-ascii"

hi guys, wondering if someone might know why my pool is still allocated
1.45T after I removed the files on the LU's provisioned onto that pool.


 pool: pool02
 state: ONLINE
  scan: scrub in progress since Wed Oct  8 02:31:41 2014
    29.1G scanned out of 1.45T at 52.4M/s, 7h54m to go
    0 repaired, 1.96% done
config:

        NAME                       STATE     READ WRITE CKSUM
        pool02                     ONLINE       0     0     0
          mirror-0                 ONLINE       0     0     0
            c4t5000C500570858EFd0  ONLINE       0     0     0
            c4t5000C50057085A6Bd0  ONLINE       0     0     0
          mirror-1                 ONLINE       0     0     0
            c4t5000C500570870D3d0  ONLINE       0     0     0
            c4t5000C50057089753d0  ONLINE       0     0     0
        logs
          c11d0                    ONLINE       0     0     0
        cache
          c13d0                    ONLINE       0     0     0
          c15d0                    ONLINE       0     0     0


Supporting 3 LU's mounted in Vmware, I formatted the LUNs again and no
change...

Do I really  need to delete the pool, then re-create it?

br,
Rune

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6247 bytes
Desc: not available
URL: <https://omniosce.org/ml-archive/attachments/20141008/0b8b0799/attachment.bin>