Re: [List] Cannot find out what uses space in ZFS dataset
- In reply to: Andrea Venturoli : "Re: [List] Cannot find out what uses space in ZFS dataset"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Mon, 22 Sep 2025 18:12:33 UTC
> 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