In part 2 of this little story about storage use in TFS, we had a look at how the storage was consumed by areas. One of the biggest areas are usually related to build jobs.
If you are using GIT in previous releases of TFS, you might see a large growth in data, as the retention policy wasn’t able to do a proper cleanup.
To identify this and/or see how the storage is consumed by the different parts of the build system, execute the following query on your collection:
SELECT CASE WHEN Container = 'vstfs:///Buil' THEN 'Build' WHEN Container = 'vstfs:///Git/' THEN 'Git' WHEN Container = 'vstfs:///Dist' THEN 'DistributedTask' WHEN Container = 'vstfs:///Rele' THEN 'Release' ELSE Container END AS FileContainerOwner, SUM(fm.CompressedLength) / 1024 / 1024 AS TotalSizeInMB FROM (SELECT DISTINCT LEFT(c.ArtifactUri, 13) AS Container, fr.ResourceId, ci.PartitionId FROM tbl_Container c with (nolock) INNER JOIN tbl_ContainerItem ci ON c.ContainerId = ci.ContainerId AND c.PartitionId = ci.PartitionId INNER JOIN tbl_FileReference fr ON ci.fileId = fr.fileId AND ci.DataspaceId = fr.DataspaceId AND ci.PartitionId = fr.PartitionId) c INNER JOIN tbl_FileMetadata fm ON fm.ResourceId = c.ResourceId AND fm.PartitionId = c.PartitionId GROUP BY c.Container ORDER BY TotalSizeInMB DESC
In TFS 2018, the GIT retention issue was fixed, and you should see a drop in consumed storage, 3 weeks (default retention time) after you have upgraded.