On the backend of things in regards to dedupe. You have these "container files." (*.bin)
They are a certain size (I don't recall off hand, but it emulates AIT tape media). They fill up with deduplication data, and as it fills up, a new .BIN is created. The full size is allocated up front to prevent file fragmentation.
So now you have hundreds or thousands of *.BIN files of about 100MB or so each. Data expires in your DLM, but only the markers in the database/catalogs get marked as expired/overwrittable data within the container. The container is still 100MB. Again to prevent file fragmentation.
You could have a number of half full or even "empty," container files, but they still consume a fixed amount of space, 100MB. You have to wait for the weekly garbage collection to compact and free up space, or you can run it manually. This will go into the containers and try to consolidate the *.BIN's to make them all full.
So now you know the backend, on the front end you have your OST media files, that map to a piece of physical media (.bin). Data will be updating, overwriting, or appending to existing containers based on the retention of the media sets, as well as the segments/bits of data that make up the container file.
(Sorry many of your question related specifically to DLM, and I don't know it well enough, but PKH has written a decent article on them, in the blogs or article section of the forums)
