drop table does not free up disk space
We have an (unbalanced) cluster where 2-3 nodes (out of a total of 10) are desperately running out of disk space (like 95-97% full in data partitions).
My question is why does a DROP TABLE not reduce the disk space utilization, even hours after dropping the table. This is a relatively large table (5 TB, out of an total license of 40TB).
I was under the impression that dropping a table freed up all disk storage resources associated with that table.
0
Comments
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.