drop table does not free up disk space

did you use drop table cascade?

No, but the DROP didn't complain like it usually does if there are any dependencies that prevent the table from being dropped.

Now that the table is dropped, is there a way to ensure that the storage for the table is freed up?

Did you try

select * from V_MONITOR.DISK_STORAGE;

and select * from  v_monitor.storage_containers to find containers referenced with your table?

 In some cases, depending on the size of the table , the operational system will take time to reclaim the space.

 It happened to me as well. 

You mean that you can't spot your comtainer in select * from  v_monitor.storage_containers but its still on disk anyway?

I mean that i can query the v_monitor.storage_containers table and i don`t see it but i can see it in the projection_storage table and also my operation system does not show the released space.

 When i drop small projections thespace is released fast but when i drop big projections space is released not that fast.

Understood. It's really interesting how exactly Vertica translate OS command to drop container file and why it takes some time. I think that one of the Vertica Achitects should answer this question. Do you have officail tech support?

 We do at the moment , but i i will not open a ticket for this, it might be that some process was using that file on the operational system and until it realeses it the OS will not show the space reclaim, or maybe inode stuff. not really sure, but i don`t think is something that i would losse time it investigate.

Did the space reclaim succeed after a while ? I also think there was an inode still referecing the file, or perhaps a backup in progress, but most likely , by now the space reclaim succeeded.  Usually i find space reclaim to occur shortlyafter, but slowly, at the mercy of the file system ( ext3/4) i believe. 

We had a similar experience.  To resolve this issue, we ended up adding 2 additional nodes, and rebalancing.