Skip site navigation (1)Skip section navigation (2) 
Date:      Mon, 22 Sep 2025 20:12:33 +0200
From:      freebsd@vanderzwan.org
To:        Andrea Venturoli <ml@netfence.it>
Cc:        questions@freebsd.org
Subject:   Re: [List] Cannot find out what uses space in ZFS dataset
Message-ID:  <9EE7C5E7-14D4-4E0E-8397-9977440520CC@vanderzwan.org>
In-Reply-To: <4d41d6dc-a162-4182-a032-6c9a04fbfd25@netfence.it>
References:  <8edc1a9d-bad8-4d35-8e90-b750eec84e0a@netfence.it> <b056fd28-4b48-453f-9da3-299a842ffc32@fjl.co.uk> <16810449-2952-4257-b8d4-d74e03a18ff4@netfence.it> <09543B55-0259-4CCD-B56B-49FAACFB9663@vanderzwan.org> <804e8cad-e197-4ce0-b8cf-7ee326a53a94@netfence.it> <7C87A153-C197-486B-B67E-81542D9BBDA6@vanderzwan.org> <344daf02-f1e2-4be3-9c65-834d9582197f@netfence.it> <5841211A-B05C-40FF-953E-87B7A377B7AD@vanderzwan.org> <c2e70410-ffa4-41e5-a15c-71fc2c536b5d@netfence.it> <7F88E7F0-6B24-4E5B-AEBE-BF67D623FAEF@vanderzwan.org> <dcfcca39-611c-41f6-8b6a-91b90dcf6f24@netfence.it> <B9DE59A7-89D7-489E-A94C-5EA10F00226F@vanderzwan.org> <4c460392-04d3-4d28-bf52-753a84ac188f@netfence.it> <31F76B72-CE2C-47B4-AA5C-A4BDD3C9FB03@vanderzwan.org> <6376c8ce-a83d-46ac-9d52-514f2e034f08@netfence.it> <9B7D6F88-DC5C-48AC-A1F8-51ADEBA9CF3B@vanderzwan.org> <E579D721-8042-46C3-9F7B-2444580135D2@vanderzwan.org> <4d41d6dc-a162-4182-a032-6c9a04fbfd25@netfence.it>
index | next in thread | previous in thread | raw e-mail 



> On 22 Sep 2025, at 08:12, Andrea Venturoli <ml@netfence.it> wrote:
> 
> On 9/22/25 07:15, freebsd@vanderzwan.org wrote:
>>> On 22 Sep 2025, at 07:12, freebsd@vanderzwan.org wrote:
>>> 
>>> 
>> You need zdb with 5 d’s to get the name. So 'zdb -ddddd zroot/ROOT/ default  360’
> 
> Here it is:
> 
>> Dataset zroot/ROOT/default [ZPL], ID 89, cr_txg 8, 62.1G, 105865 objects, rootbp DVA[0]=<0:a861f85000:1000> DVA[1]=<0:311e6461000:1000> [L0 DMU objset] fletcher4 uncompressed unencrypted LE contiguous unique double size=800L/800P birth=>
>>    Object  lvl   iblk   dblk  dsize  dnsize  lsize   %full  type
>>       360    3   128K   128K  58.8G     512  90.0G  100.00  ZFS plain file
>>                                               168   bonus  System attributes
>>        dnode flags: USED_BYTES USERUSED_ACCOUNTED         dnode maxblkid: 737498
>>        path    on delete queue
>>        uid     0
>>        gid     0
>>        atime   Wed Jun 25 14:50:38 2025
>>        mtime   Wed Jun 25 15:02:31 2025
>>        ctime   Wed Jun 25 15:02:31 2025
>>        crtime  Wed Jun 25 14:50:38 2025
>>        gen     35226387
>>        mode    100644
>>        size    96665427448
>>        parent  87
>>        links   0
>>        pflags  40800000004
>> Indirect blocks:
>>               0 L2   0:ad0c152000:9000 20000L/9000P F=737499 B=35226471/35226471 cksum=00000cf77c955f23:00f9a3345e9c1658:c3f286e3bc2c2a99:42b808e738c1f99e
>>               0  L1  0:ad0042d000:b000 20000L/b000P F=1024 B=35226388/35226388 cksum=00001115fae7065c:019128fbafb5a2bc:0701bd8b4bd05900:3417736fdef1ad6c
>>               0   L0 0:19007486000:1c000 20000L/1c000P F=1 B=35226387/35226387 cksum=00002fe112352d05:0a003c91dad6a92b:ddd312e24d14537f:b7df15b3fff44a4c
>>           20000   L0 0:19007872000:8000 20000L/8000P F=1 B=35226387/35226387 cksum=00001019b66eb88a:0133b13699ec22cf:cc2e684318f9738e:57bbf713d899e173
>>           40000   L0 0:1900e2d9000:2000 20000L/2000P F=1 B=35226387/35226387 cksum=00000160676ba5c7:00078f59aec453a5:165bf3de05b5543e:8c0213aacf6abbe2
>>           60000   L0 0:190075fb000:c000 20000L/c000P F=1 B=35226387/35226387 cksum=00001515331d9638:01f977317121e464:b07853739191bafd:85837809e155832f
>>           80000   L0 0:190285a7000:20000 20000L/20000P F=1 B=35226387/35226387 cksum=00003ec18e9e1e3e:0fad53262d5c9c67:a0632107020a024c:6b5dffbf9d374376
> >...
>>      1681b20000   L0 0:28bc1027000:20000 20000L/20000P F=1 B=35226471/35226471 cksum=00003e64c67aad30:0f930395d4c3b7f8:eaff9bb33545afd3:12c9a6423c2b5b5a
>>      1681b40000   L0 0:28b9df38000:d000 20000L/d000P F=1 B=35226471/35226471 cksum=0000175a6f6b02e3:029bcd30daa5d07b:edd314a460c8181d:5b6ad7fe80996b0a
>>                segment [0000000000000000, 0000001681b60000) size 90.0G
> 
> 
> No filename unfortunately, but "path    on delete queue" gives an hint!
> I think I've read some thread on "delete queue" not being worked on... I'll have to search again.
> 

The delete queue should be gone when pool is re-mounted after reboot, so that's weird.
I have no idea if/how you can try to force it, or if it's a matter of more patience..

Good luck ;-)

	Paul
help

Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9EE7C5E7-14D4-4E0E-8397-9977440520CC>