You can use sys.dm_db_index_physical_stats to identify the size of your partitions and how much space is being used. Use the
page_count field to see the size of your partition. If you perform a SAMPLED or DETAILED scan, you will also get a value for
avg_page_space_used_in_percent, which will allow you to estimate how much of the space in the partition is actually being used.
,(di.page_count/128.0) * di.avg_page_space_used_in_percent * .01 [space_used_MB]
join sys.dm_db_index_physical_stats(DB_ID(),object_id('<Table Name'>), NULL, NULL, 'SAMPLED') di
on i.object_id = di.object_id and i.index_id = di.index_id
If you want to check the free space in the actual files themselves, I recommend using a query from Glenn Berry's DMV script.
SELECT f.name AS [File Name] , f.physical_name AS [Physical Name],
CAST((f.size/128.0) AS DECIMAL(15,2)) AS [Total Size in MB],
CAST(f.size/128.0 - CAST(FILEPROPERTY(f.name, 'SpaceUsed') AS int)/128.0 AS DECIMAL(15,2))
AS [Available Space In MB], [file_id], fg.name AS [Filegroup Name]
FROM sys.database_files AS f WITH (NOLOCK)
LEFT OUTER JOIN sys.data_spaces AS fg WITH (NOLOCK)
ON f.data_space_id = fg.data_space_id OPTION (RECOMPILE);
This should give you a rough idea of whether or not you have any space to reclaim. As for actually reclaiming it, it depends on what you need to do. If your files are simply over provisioned, you can shrink them using DBCC SHRINKFILE (this is not something that should be done regularly). If, however, the files are mostly full but you have free space within the partitions, try rebuilding the indexes to reclaim some of the space (likely lost due to fragmentation). If the disk is full and there isn't space in the partitions, consider archiving data off to another disk system or to offline storage.
That all being said, 100 million rows really isn't that much data and I'm curious as to why partitioning was even chosen as a solution. It's a lot of overhead without a lot of benefit to you.