Any chance you might have orphaned `rados bench` objects ? This happens more than one might think. `rados ls > /tmp/out` Inspect the result. You should see a few administrative objects, some header and data objects for the RBD volume. If you see a zillion with names like `bench*` there’s your culprit. Those can be cleaned up. > On Dec 12, 2020, at 11:42 PM, mk <mk@xxxxxx> wrote: > > Hi folks, > my cluster shows strange behavior, the only ssd pool on cluster with repsize 3 and pg/pgp size 512 > which contains 300GB rbd image and only one snapshot occupies 11TB space! > > I have tried objectmap check / rebuild, fstrim etc. which couldn’t solve that problem, any help would be appreciated. > > > ceph version 14.2.7 nautilus (stable) > > > ceph df > ------- > RAW STORAGE: > CLASS SIZE AVAIL USED RAW USED %RAW USED > hdd 107 TiB 68 TiB 39 TiB 39 TiB 36.45 > ssd 21 TiB 11 TiB 11 TiB 11 TiB 50.78 > TOTAL 128 TiB 78 TiB 50 TiB 50 TiB 38.84 > > POOLS: > POOL ID STORED OBJECTS USED %USED MAX AVAIL > ssdshop 83 3.5 TiB 517.72k 11 TiB 96.70 124 GiB > > > rados df > -------- > POOL_NAME USED OBJECTS CLONES COPIES MISSING_ON_PRIMARY UNFOUND DEGRADED RD_OPS RD WR_OPS WR USED COMPR UNDER COMPR > ssdshop 11 TiB 537040 28316 1611120 0 0 0 11482773 15 GiB 44189589 854 GiB 0 B 0 B > > > > rbd du -p ssdshop > ----------------- > NAME PROVISIONED USED > shp-de-300gb.rbd@snap_2020-12-12_20:30:00 300 GiB 289 GiB > shp-de-300gb.rbd 300 GiB 109 GiB > <TOTAL> 300 GiB 398 GiB > > > crush_rule > ----------- > rule ssd { > id 3 > type replicated > min_size 1 > max_size 10 > step take dc1 class ssd > step chooseleaf firstn 2 type rack > step emit > step take dc2 class ssd > step chooseleaf firstn -1 type rack > step emit > } > > BR > Max > _______________________________________________ > ceph-users mailing list -- ceph-users@xxxxxxx > To unsubscribe send an email to ceph-users-leave@xxxxxxx _______________________________________________ ceph-users mailing list -- ceph-users@xxxxxxx To unsubscribe send an email to ceph-users-leave@xxxxxxx