Once SQL Server acquires disk space from the operating system and allocates it to a database it will not voluntarily give it back. It takes time and effort to allocate this space so it is more efficient for the database to hang onto it once it has acquired it. If you genuinely have moved the data and not copied it (you would have to post your SQL for us to be sure) there will be a lot of free space in the files of the PRIMARY filegroup. Have a look at this post for hints how to find the free space in a file.
To force SQL Server to hand back this free space to the operating system you will have to uses a SHRINK command. This is well documented in Books Online. There are potential performance problems with SHRINK, so use it after proper consideration.
Ordinarily, SQL Server only checks for a read-only filegroup just before attempting to write to the partition. No error is thrown when reading from a read-only filegroup, as you would expect.
SQL Server can therefore touch any rows it likes, so long as only rows located on read-write filegroups qualify for the update. To put it another way: SQL Server can fully scan all partitions (e.g. using a Clustered Index Scan) looking for rows to update, so long as the only rows that arrive at the Clustered Index Update are on read-write partitions.
In this scenario, there are two separate storage engine rowsets involved: one for the read, and one for the update. The reading rowset will not throw an error if it encounters a read-only partition because it is only reading. The writing rowset will throw an error, because it is configured to perform changes.
The catch
In execution plan shapes where there is no blocking operator between reads and writes to the base table, SQL Server may apply an optimization ("Rowset Sharing"), whereby the two operators share a single storage engine rowset.
In this situation, reading from a read-only partition will throw the error reported in the question. The single rowset is configured for both read and write - touching a read-only partition results in the error.
Adding a key from the unique clustered index to the set clause means a split, sort, collapse combination is required to avoid transient key violations. As a side-effect, the sort (a blocking operator) prevents the rowset sharing optimization from being applied.
For more details, see my article Changes to a Writable Partition May Fail Unexpectedly
Best Answer
One reason is that new data was allocated but old not cleared. This is partially because it is not available immediatly, the other reason may be that SQL Server has to wait until partitioning finishes to delete the old table. if you are considered by that (which I find funny - heck, it is even funny partitioning a very small table on a tiny database of 5gb) then you may shrink the file to reclaim the space. THAT SAID: perforamnce oriented databases should not autogrow to start with ;)